Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Sep 2011 23:03:27 +0100
From:      "Torsten Kersandt" <>
To:        "'Mario Lobo'" <>, <>
Subject:   RE: VPN  problem
Message-ID:  <033101cc6f3c$4dfc8f20$e9f5ad60$@net>
In-Reply-To: <>
References:  <>	<032f01cc6f35$162e1390$428a3ab0$@net> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
TUN and NG connections are not present at the time you start your server and
rules for such interfaces are not applicable to PF

The is there the if up and if down functions of MPD come into place unless
you use IP Address/network specific rules.
One server I have in the if-up script:

/etc/rc.d/pf resync
/sbin/pfctl -t if_pptp -T add ${4}

And it works perfectly fine including on the secondary MPD instance (bound
to IP address) allowing usage as default gateway functions.

Other than that I think you will have to go down the bridging line.
I may be corrected bu others :-)


-----Original Message-----
From: [] On
Behalf Of Mario Lobo
Sent: 09 September 2011 22:53
Subject: Re: VPN problem

On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote:
> HI Mario
> I don't know what the experts are suggesting but I use a table for the VPN
> addresses
> To allow nat but block them frm using the server as gateway ("use as
> default gateway" disabled in windows)
> I add the rules dynamically using mpd if-up and if-down scripts
> All I have in my rules is GRE pass anywhere and nat <table> to and from
> where ever
> Regards
> Torsten

Thanks for replying, Torsten but the problem is way before all these things 
that you mentioned. I'm wildly guessing here but the problem seems to be 
inside the NAT mechanism of PF. At least the working/not working situations 
point to that direction.

If I don't find a solution to that soon I am gonna have no choice but to 
switch to IPFW, which I would not like to do because the queuing mechanisms
pf are extremely useful and handy to my networks.

By the way, I also do each item that you mentioned in your post.

The funny thing is that there was a time (maybe a couple csups ago) that
problem didn't occur, and I am totally unable to say which csup brought this

issue in. Remeber there are 3 FBSDs involved here.

Mario Lobo
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE)

> -----Original Message-----
> From: []
> Behalf Of Mario Lobo
> Sent: 09 September 2011 20:46
> To:
> Cc:
> Subject: VPN problem
> Hi;
> I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE
> with pf.
> I have this scenario:
> home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN
>                                              MPD VPN server
> nat rules on FBSD+pf home:
>  nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535
>  # nat on $ext_if from any to any -> ($ext_if) port 1024:65535
> obs- it makes no difference which nat rule I use. The problem persists.
> These are the first 5 pf rules on FBSD+pf home:
>   # pass quick all
>   pass quick on lo0 all
>   # my whole home lan is free
>   pass in quick on $int_if from $int_if:network to any
>   #--- Allow networks to see themselves and dns
>   pass quick from $int_if:network to $int_if:network
>   #--- Allow vpns from anywhere to anywhere
>   pass in quick log on $int_if proto gre from any to any keep state
>   pass in quick log on $int_if proto tcp from any to any port pptp flags
> S/SA
> keep state
> On any attempt to connect to the FBSD+pf work VPN Server from home LAN,
> I get this (even if I uncomment  pass quick all):
> #>mpd5
> Multi-link PPP daemon for FreeBSD
> process 98799 started, version 5.5 (root@Papi 16:55  3-Sep-2011)
> CONSOLE: listening on 5005
> web: listening on 5006
> [B1] Bundle: Interface ng0 created
> [L1] [L1] Link: OPEN event
> [L1] LCP: Open event
> [L1] LCP: state change Initial --> Starting
> [L1] LCP: LayerStart
> [L1] PPTP call successful
> [L1] Link: UP event
> [L1] LCP: Up event
> [L1] LCP: state change Starting --> Req-Sent
> [L1] LCP: SendConfigReq #1
> [L1]   ACFCOMP
> [L1]   ACCMAP 0x000a0000
> [L1]   MRU 1486
> [L1]   MAGICNUM 2d08ae01
> [snip..]
> [L1] LCP: SendConfigReq #10
> [L1]   ACFCOMP
> [L1]   ACCMAP 0x000a0000
> [L1]   MRU 1486
> [L1]   MAGICNUM 2d08ae01
> [L1] LCP: parameter negotiation failed
> [L1] LCP: state change Req-Sent --> Stopped
> [L1] LCP: LayerFinish
> [L1] PPTP call terminated
> [L1] Link: DOWN event
> [L1] LCP: Close event
> [L1] LCP: state change Stopped --> Closed
> [L1] LCP: Down event
> [L1] LCP: state change Closed --> Initial
> BUT, on the 9th or 10th attempt, without touching any setting anywhere,
> VPN MAY BE established. out of nothing ! Machines (Windows, Unix,
> behind both FBSD+pfs ALSO have the same problem when trying to close VPN
> tunnels to outside sites.
> Sometimes, opening an ssh session from my workstation to FBSD+pf work may
> "help" in establishing the VPN.
> The FBSD+pf work VPN Server is working fine. My colleagues can connect to
> it
> from their homes (NATted cable modems or 3G modems) without problems. I am
> the
> only one behind a FBSD+pf router.
> I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home
> workstation
> to it.
> Without touching a single setting on mpd.conf, the VPN is established
> from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on
> SINGLE attempt! even I bring it up/down 200 times!
> And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the
> case
> of FBSD+pf home as a client) or if I let my cable modem do the
> the problem is GONE!.
> FreeBSD work
> FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64
> FreeBSD Home
> FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386
> Any suggestions?
> Thanks,
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Want to link to this message? Use this URL: <$4dfc8f20$e9f5ad60$>