Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Sep 2011 18:53:08 -0300
From:      Mario Lobo <lobo@bsd.com.br>
To:        freebsd-pf@freebsd.org
Cc:        freebsd-questions@freebsd.org
Subject:   Re: VPN  problem
Message-ID:  <201109091853.09133.lobo@bsd.com.br>
In-Reply-To: <032f01cc6f35$162e1390$428a3ab0$@net>
References:  <201109091646.15327.lobo@bsd.com.br> <032f01cc6f35$162e1390$428a3ab0$@net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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 of 
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 this 
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
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE)

> 
> -----Original Message-----
> From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On
> Behalf Of Mario Lobo
> Sent: 09 September 2011 20:46
> To: freebsd-pf@freebsd.org
> Cc: freebsd-questions@freebsd.org
> 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 127.0.0.1 5005
> web: listening on 127.0.0.1 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]   PROTOCOMP
> [L1]   ACCMAP 0x000a0000
> [L1]   MRU 1486
> [L1]   MAGICNUM 2d08ae01
> 
> [snip..]
> 
> [L1] LCP: SendConfigReq #10
> [L1]   ACFCOMP
> [L1]   PROTOCOMP
> [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, the
> VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever)
> 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
> EVERY
> 
> 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 NAT/routing,
> 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,



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?201109091853.09133.lobo>