Skip site navigation (1)Skip section navigation (2)
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>