Date: Sun, 11 Sep 2011 11:06:03 -0500 From: Brad Tarver <idl3mind@gmail.com> Cc: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Re: VPN problem Message-ID: <788356111728596465@unknownmsgid> In-Reply-To: <201109091853.09133.lobo@bsd.com.br> References: <201109091646.15327.lobo@bsd.com.br> <032f01cc6f35$162e1390$428a3ab0$@net> <201109091853.09133.lobo@bsd.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
I've not setup a freebsd VPN yet. Correct me if I'm wrong but for VPN
use wouldn't you want to exclude your private subnets from NAT?
--
Brad Tarver
Sent from my iPhone 4
On Sep 9, 2011, at 4:55 PM, Mario Lobo <lobo@bsd.com.br> wrote:
> 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,
> _______________________________________________
> freebsd-pf@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?788356111728596465>