Difficulties establishing VPN tunnel with IPNAT

Ted Mittelstaedt tedm at toybox.placo.com
Sun Nov 25 03:41:21 PST 2007 

That's an absolutely terrible reason.

On FreeBSD and the other open source operating systems there
are always multiple ways to solve a problem.  While in a few
situations it can definitively be stated that one program is
better (for example, sendmail is obviously superior to qmail)
in most situations the different programs are merely different.
The "better" one is the one that works for YOUR problem the
best.  Not the one that works for someone else's problem.

ipf is no better than ipfw for most purposes, it's just different.
In this case, you had a working solution and now you don't.  So,
clearly, in your case, it's WORSE.

Ted

> -----Original Message-----
> From: Jerahmy Pocott [mailto:quakenet1 at optusnet.com.au]
> Sent: Sunday, November 25, 2007 2:12 AM
> To: Ted Mittelstaedt
> Cc: Roger Olofsson; FreeBSD Questions
> Subject: Re: Difficulties establishing VPN tunnel with IPNAT
> 
> 
> 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 at freebsd.org
> >> [mailto:owner-freebsd-questions at 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 at freebsd.org mailing list
> >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >>>>> To unsubscribe, send any mail to
> >>>>> "freebsd-questions-unsubscribe at freebsd.org"
> >>>> _______________________________________________
> >>>> freebsd-questions at freebsd.org mailing list
> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >>>> To unsubscribe, send any mail to
> >>>> "freebsd-questions-unsubscribe at freebsd.org"
> >>>
> >>> _______________________________________________
> >>> freebsd-questions at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >>> To unsubscribe, send any mail to
> >>> "freebsd-questions-unsubscribe at freebsd.org"
> >>>
> >>>
> >> _______________________________________________
> >> freebsd-questions at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >> To unsubscribe, send any mail to
> >> "freebsd-questions-unsubscribe at freebsd.org"
> >>
> >
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions- 
> > unsubscribe at freebsd.org"
> 
>

More information about the freebsd-questions mailing list