Is it possible that you have multiple addresses on $ext_if? You NAT it to the first one (:0), but tunnel established using FQDNs could try to send stuff to another IP that doesn't match your NAT table. Have you actually seen anything going out of the external boxes on your firewall? Pflog and tcpdump are your friends...
2010/5/13, dontek <[email protected]>: > I have tried adding a pass in proto esp with no change to my working status. > (tunnel uses ESP) > > If you would like to return my pf.conf with the rule(s) in the positions you > think should be necessary, I will try it and report back. > > Thanks for trying, any other ideas? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jorge Enrique Valbuena Vargas > Sent: Wednesday, May 12, 2010 12:59 PM > To: Misc OpenBSD > Subject: Re: VPN Clients Behind OpenBSD 4.6 PF NAT > > hi, > > what about pass in and pass out with proto esp or ah ? > > > > > > > On Mon, May 10, 2010 at 6:23 PM, dontek <[email protected]> wrote: > >> The only change to sysctl.conf from default install is uncommenting: >> >> net.inet.ip.forwarding=1 >> net.inet6.ip6.forwarding=1 >> >> I am running a slightly pruned version of the FAQ "Example: Firewall for >> Home or Small Office" pf.conf. >> ----------------------------------------------------------------- >> ext_if="fxp0" >> int_if="xl0" >> >> tcp_services="{ 22 }" >> icmp_types="echoreq" >> >> set block-policy return >> set loginterface $ext_if >> >> set skip on lo >> >> match in all scrub (no-df) >> >> nat on $ext_if from !($ext_if) -> ($ext_if:0) >> nat-anchor "ftp-proxy/*" >> rdr-anchor "ftp-proxy/*" >> >> rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021 >> >> block in >> >> pass out keep state >> >> anchor "ftp-proxy/*" >> >> antispoof quick for { lo $int_if } >> >> pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services >> flags S/SA keep state >> >> pass in inet proto icmp all icmp-type $icmp_types keep state >> >> pass in quick on $int_if >> ----------------------------------------------------------------- >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Jorge Enrique Valbuena Vargas >> Sent: Monday, May 10, 2010 5:47 PM >> To: Don Reis >> Cc: [email protected] >> Subject: Re: VPN Clients Behind OpenBSD 4.6 PF NAT >> >> HI, >> >> can you send the pf.conf and sysctl.conf files ? >> >> >> >> On Mon, May 10, 2010 at 2:56 PM, Don Reis <[email protected]> wrote: >> >> > Hey guys, I got a little problem: >> > >> > >> > >> > First let me say I am running a fresh install of OpenBSD 4.6 and besides >> > turning on IP forwarding in sysctl and installing the pf.conf example >> from >> > the FAQ (modified of course to fit my NIC's), I have changed nothing in >> the >> > default install. >> > >> > >> > >> > The scenario is I am attempting to connect to various external VPN's > from >> > inside my NAT network. I have tried both the Cisco and Shrew Soft VPN >> > Clients with various Cisco and Netgear VPN concentrators and appliances, >> > all >> > with the exact same results. >> > >> > >> > >> > I initiate the connection, Phase 1 completes, Phase 2 completes, the >> tunnel >> > comes up. I'm connected now right, except, packets only flow one >> direction >> > over the tunnel, my outbound traffic gets through the tunnel to the >> remote >> > network, but nothing ever comes back. >> > >> > >> > >> > If I jack my computer directly into my internet connection, everything > is >> > peachy on all clients and all endpoints. >> > >> > >> > >> > I've searched quite a bit and almost all of what I find is people >> > complaining they can't get a connection over NAT and other people >> > recommending various port redirects to a single machine running the VPN >> > client to make things work. >> > >> > >> > >> > This is of course not like my situation. All VPN negotiations work just >> > fine, I just never receive anything over the tunnel once it's up. >> > >> > >> > >> > Give me a clue. I assume this should just work behind PF NAT, since > both >> > clients are negotiating and using NAT-T. >> > >> > >> > >> > Thanks, >> > >> > >> > >> > don.. > > -- Martin PelikC!n, Steadynet E-mail: [email protected], gpg key 0x7176E4C9 Tel: +420 724 818 573 Jabber: [email protected] web: http://cap.potazmo.cz/
