Date: Sun, 25 Nov 2007 01:00:41 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Roger Olofsson" <raggen@passagen.se>, "Jerahmy Pocott" <quakenet1@optusnet.com.au> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: RE: Difficulties establishing VPN tunnel with IPNAT Message-ID: <BMEDLGAENEKCJFGODFOCOEBNCFAA.tedm@toybox.placo.com> In-Reply-To: <4748A115.1010002@passagen.se>
next in thread | previous in thread | raw e-mail | index | archive | help
The other thing you can do is simply switch back to natd. You didn't say why you decided to switch in the first place. A lot of times people switch because they are having problems with natd. Are you? If not, you should be aware that natd does support more kinds of protocol translations. Ted > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Roger Olofsson > Sent: Saturday, November 24, 2007 2:09 PM > To: Jerahmy Pocott > Cc: FreeBSD Questions > Subject: Re: Difficulties establishing VPN tunnel with IPNAT > > > Hello again Jerahmy, > > I would suggest that you verify what port(s) and protocol(s) 'Sonic Wall > Global VPN Client' needs to work. > > I would also suggest that you look in the logfile from ipf to see what > it's blocking and when. > > My guess is that the VPN client is using a protocol like IPSEC (IP > protocol 50) and possibly port 500 (IKE) for which you will have to > activate the ipnat proxy. > > map WAN internal_ip/24 -> 0.0.0.0/32 proxy port 500 ipsec/udp > > You might also try to disable the blocking of fragged packets. For some > VPN clients this can cause problems. > > Good luck! > > /Roger > > > > Jerahmy Pocott skrev: > > Sorry let me clarify.. > > > > There are two issues, one is connecting to any external VPN, with no > > filter I > > can establish a connection to PPTP VPN, but the 'Sonic Wall Global VPN > > Client' > > still fails to connect even with no filter rules. > > > > The redirect for the CVS server has an ipf rule to allow > traffic on that > > port, but > > users are getting connection refused messages. > > > > I will include my ipf rules, I clearly need some sort of rule to allow > > inbound for > > the VPN to work, though I think the ipnat is breaking the Sonic Wall > > client. Which > > is strange because everything worked fine with ipfw/natd. > > > > Here are my ipf rules: > > > > # Allow all in/out on internel interface > > pass in quick on fxp0 all > > pass out quick on fxp0 all > > > > # Allow all in/out on loopback interface > > pass in quick on lo0 all > > pass out quick on lo0 all > > > > # Allow all out-going on public interface and keep state > > pass out quick on fxp1 proto tcp from any to any flags S keep state > > pass out quick on fxp1 proto udp from any to any keep state > > pass out quick on fxp1 proto icmp from any to any keep state > > > > # Block all inbound traffic from non-routable or reserved address spaces > > block in quick on fxp1 from 192.168.0.0/16 to any #RFC 1918 > private IP > > block in quick on fxp1 from 172.16.0.0/12 to any #RFC 1918 > private IP > > block in quick on fxp1 from 10.0.0.0/8 to any #RFC 1918 > private IP > > block in quick on fxp1 from 127.0.0.0/8 to any #loopback > > block in quick on fxp1 from 0.0.0.0/8 to any #loopback > > block in quick on fxp1 from 169.254.0.0/16 to any #DHCP auto-config > > block in quick on fxp1 from 192.0.2.0/24 to any #reserved for docs > > block in quick on fxp1 from 204.152.64.0/23 to any #Sun cluster > > interconnect > > block in quick on fxp1 from 224.0.0.0/3 to any #Class D & > E multicast > > # Block frags > > block in quick on fxp1 all with frags > > # Block short tcp packets > > block in quick on fxp1 proto tcp all with short > > # block source routed packets > > block in quick on fxp1 all with opt lsrr > > block in quick on fxp1 all with opt ssrr > > # Block anything with special options > > block in quick on fxp1 all with ipopts > > # Block public pings > > block in quick on fxp1 proto icmp all icmp-type 8 > > # Block ident > > block in quick on fxp1 proto tcp from any to any port = 113 > > # Block all Netbios service. 137=name, 138=datagram, 139=session > > # Block MS/Windows hosts2 name server requests 81 > > block in quick on fxp1 proto tcp/udp from any to any port = 137 > > block in quick on fxp1 proto tcp/udp from any to any port = 138 > > block in quick on fxp1 proto tcp/udp from any to any port = 139 > > block in quick on fxp1 proto tcp/udp from any to any port = 81 > > > > # Allow CVS access > > pass in quick on fxp1 proto tcp/udp from any to any port = 2401 > > > > # Logged Blocking Rules # > > > > # Block nmap OS fingerprint attempts > > block in log first quick on fxp1 proto tcp from any to any flags FUP > > > > # Block all other in coming traffic > > block in log first quick on fxp1 all > > > > Thanks for the help! > > J. > > > > On 25/11/2007, at 12:50 AM, Roger Olofsson wrote: > > > >> Hello Jerahmy, > >> > >> Assuming you want to connect from the outside to your VPN. > >> > >> Have you made sure that port 2401 is open for inbound traffic in your > >> ipf.rules? > >> > >> You might also want to do 'ipnat -C -f <path to ipnat.rules>'. Man > >> ipnat ;^) > >> > >> Greeting from Sweden > >> /Roger > >> > >> > >> > >> Jerahmy Pocott skrev: > >>> Hello, > >>> I recently decided to give ipf and ipnat a try, previously I had > >>> always been using > >>> ipfw and natd. Since switching over I can no longer establish a VPN > >>> tunnel from > >>> any system behind the gateway. > >>> I did 'ipf -F a' to flush all rules but I was still unable to connect > >>> so I think it's a problem > >>> with ipnat? Also my redirect from ipnat doesn't seem to work either. > >>> These are the only ipnat rules I have: > >>> (fxp1 is the external interface) > >>> # ipnat built in ftp proxy rules > >>> map fxp1 10.0.0.0/24 -> 0/32 proxy port 21 ftp/tcp > >>> map fxp1 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp > >>> # CVS Server on Fileserv > >>> rdr fxp1 0/32 port 2401 -> 10.0.0.2 port 2401 tcp/udp > >>> # nat all out going traffic on fxp1 from internal lan > >>> map fxp1 10.0.0.0/24 -> 0/32 > >>> I can post my firewall rules too if that would help, however with NO > >>> rules set it > >>> still didn't work so I don't think that would help.. (I'm using the > >>> klm which is default > >>> to accept?) > >>> Thanks! > >>> J. > >>> _______________________________________________ > >>> freebsd-questions@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >>> To unsubscribe, send any mail to > >>> "freebsd-questions-unsubscribe@freebsd.org" > >> _______________________________________________ > >> freebsd-questions@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >> To unsubscribe, send any mail to > >> "freebsd-questions-unsubscribe@freebsd.org" > > > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > "freebsd-questions-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCOEBNCFAA.tedm>