From owner-freebsd-questions@FreeBSD.ORG Sat Nov 24 22:07:28 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A9916A419 for ; Sat, 24 Nov 2007 22:07:28 +0000 (UTC) (envelope-from raggen@passagen.se) Received: from av11-2-sn2.hy.skanova.net (av11-2-sn2.hy.skanova.net [81.228.8.184]) by mx1.freebsd.org (Postfix) with ESMTP id EA4A013C459 for ; Sat, 24 Nov 2007 22:07:27 +0000 (UTC) (envelope-from raggen@passagen.se) Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 2B1FB388A5; Sat, 24 Nov 2007 23:07:27 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 10757381BA; Sat, 24 Nov 2007 23:07:27 +0100 (CET) Received: from [192.168.1.31] (90-230-142-213-no41.tbcn.telia.com [90.230.142.213]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id E726437E45; Sat, 24 Nov 2007 23:07:26 +0100 (CET) Message-ID: <4748A115.1010002@passagen.se> Date: Sat, 24 Nov 2007 23:09:25 +0100 From: Roger Olofsson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jerahmy Pocott References: <7BB1A732-4F07-499E-A183-22776FEEEE90@optusnet.com.au> <47482C2C.6010700@passagen.se> <894E3C92-2C45-4FC2-8C56-D4B303F0349F@optusnet.com.au> In-Reply-To: <894E3C92-2C45-4FC2-8C56-D4B303F0349F@optusnet.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions Subject: Re: Difficulties establishing VPN tunnel with IPNAT X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 22:07:28 -0000 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 '. 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" > >