Date: Sun, 25 Nov 2007 21:12:14 +1100 From: Jerahmy Pocott <quakenet1@optusnet.com.au> To: Ted Mittelstaedt <tedm@toybox.placo.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org>, Roger Olofsson <raggen@passagen.se> Subject: Re: Difficulties establishing VPN tunnel with IPNAT Message-ID: <E6FFEA7E-7799-4C4E-8B44-F3EE650B1DFF@optusnet.com.au> In-Reply-To: <BMEDLGAENEKCJFGODFOCOEBNCFAA.tedm@toybox.placo.com> References: <BMEDLGAENEKCJFGODFOCOEBNCFAA.tedm@toybox.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Well the main reason is that it was part of IPF, and IPF seemed to be better than IPFW? So when trying out IPF I also used IPNAT.. I had no problems with natd but it seemed I should use the IPNAT if I was using IPF? On 25/11/2007, at 8:00 PM, Ted Mittelstaedt wrote: > > 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" >> > > _______________________________________________ > 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?E6FFEA7E-7799-4C4E-8B44-F3EE650B1DFF>