Re: Difficulties establishing VPN tunnel with IPNAT
On 27/11/2007, at 5:49 PM, Ted Mittelstaedt wrote: -Original Message- From: Jerahmy Pocott [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 4:48 AM To: Ted Mittelstaedt Cc: FreeBSD Questions Subject: Re: Difficulties establishing VPN tunnel with IPNAT Perhaps, but I'v heard a lot of good things about IPF and IPNAT, especially since the nat is all in kernel where as natd is userland, so there is a slight performance boost possibly there as well.. I will address this one point here since it's enough to make someone scream, it's such an old chestnut. natd is always criticized because going to userland is slow. So, people who have slowness problems think that is the issue. In reality, the problem is that the DEFAULT setup and man page examples for natd use the following ipfw divert rule: /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via ed0 /sbin/ipfw add pass all from any to any This produces a rule such as the following: 00050 divert 8668 ip from any to any via de0 The problem though, is this is wrong. What it is doing is that ALL traffic that comes into and out of the box - no matter what the source and destination is - will be passed to the natd translator. What you SHOULD be using is a set of commands such: ipfw add divert natd ip from any to [outside IP address] in recv [outside interface] ipfw add divert natd ip from not [outside IP address] to any out recv [inside interface] xmit [outside interface] That does make a lot of sense! How ever the 2nd rule is slightly confusing me.. Shouldn't it be something like: divert natd ip from [internal net range] to any out via [outside if]? Cheers, J. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Difficulties establishing VPN tunnel with IPNAT
-Original Message- From: Jerahmy Pocott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 7:07 AM To: Ted Mittelstaedt Cc: FreeBSD Questions Subject: Re: Difficulties establishing VPN tunnel with IPNAT On 27/11/2007, at 5:49 PM, Ted Mittelstaedt wrote: -Original Message- From: Jerahmy Pocott [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 4:48 AM To: Ted Mittelstaedt Cc: FreeBSD Questions Subject: Re: Difficulties establishing VPN tunnel with IPNAT Perhaps, but I'v heard a lot of good things about IPF and IPNAT, especially since the nat is all in kernel where as natd is userland, so there is a slight performance boost possibly there as well.. I will address this one point here since it's enough to make someone scream, it's such an old chestnut. natd is always criticized because going to userland is slow. So, people who have slowness problems think that is the issue. In reality, the problem is that the DEFAULT setup and man page examples for natd use the following ipfw divert rule: /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via ed0 /sbin/ipfw add pass all from any to any This produces a rule such as the following: 00050 divert 8668 ip from any to any via de0 The problem though, is this is wrong. What it is doing is that ALL traffic that comes into and out of the box - no matter what the source and destination is - will be passed to the natd translator. What you SHOULD be using is a set of commands such: ipfw add divert natd ip from any to [outside IP address] in recv [outside interface] ipfw add divert natd ip from not [outside IP address] to any out recv [inside interface] xmit [outside interface] That does make a lot of sense! How ever the 2nd rule is slightly confusing me.. Shouldn't it be something like: divert natd ip from [internal net range] to any out via [outside if]? As I recall the via keyword was a later addition to ipfw, the way you wrote it is the same thing - the earlier form I used works on both old and new ipfw (not that it probably matters much nowadays) Use whichever is more clear to you - the gist of it is to use the ipfw rulesets to keep the traffic that doesen't need attention of natd, out of userland. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Difficulties establishing VPN tunnel with IPNAT
-Original Message- From: Jerahmy Pocott [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 4:48 AM To: Ted Mittelstaedt Cc: FreeBSD Questions Subject: Re: Difficulties establishing VPN tunnel with IPNAT Perhaps, but I'v heard a lot of good things about IPF and IPNAT, especially since the nat is all in kernel where as natd is userland, so there is a slight performance boost possibly there as well.. I will address this one point here since it's enough to make someone scream, it's such an old chestnut. natd is always criticized because going to userland is slow. So, people who have slowness problems think that is the issue. In reality, the problem is that the DEFAULT setup and man page examples for natd use the following ipfw divert rule: /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via ed0 /sbin/ipfw add pass all from any to any This produces a rule such as the following: 00050 divert 8668 ip from any to any via de0 The problem though, is this is wrong. What it is doing is that ALL traffic that comes into and out of the box - no matter what the source and destination is - will be passed to the natd translator. What you SHOULD be using is a set of commands such: ipfw add divert natd ip from any to [outside IP address] in recv [outside interface] ipfw add divert natd ip from not [outside IP address] to any out recv [inside interface] xmit [outside interface] What these rules do is ONLY pass traffic to natd that needs natting - that is, traffic that is passing through the FreeBSD box onward to the Internet. Traffic that is broadcast, or traffic that is a destination of the nat box itself (such as if the nat box is also running a proxy server, mailserver, fileserver, etc.) or sourced from the nat box, is NOT passed to natd. There are some pretty fast Internet connections circuits out there these days - DSL and Cable can both offer up to 10Mbt of bandwidth. But, these are nothing compared to the bandwidth of a 100BaseT ethernet card, or the PCI bus of a computer. If someone is saturating their natd with filesharing traffic to the nat box, why then no wonder they are seeing things run slow. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Difficulties establishing VPN tunnel with IPNAT
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Difficulties establishing VPN tunnel with IPNAT
The Sonic Wall client doesn't trigger ANY firewall rules, which is why I thought there must be something going wrong with the NAT. It actually establishes the tunnel okay but never gets an IP address, from my understanding this client uses some sort of dhcp over ipsec to provision the client address.. What I am getting using the standard PPTP method are a bunch of hits: fxp1 @0:25 b x.x.x.x - 10.0.0.3 PR gre len 20 (93) IN NAT (rule @0:25 is the final 'block all' rule) What is protocol 'gre'? Why is a NAT'd packet getting blocked?! Thanks! J. On 25/11/2007, at 9:09 AM, Roger Olofsson wrote: 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
RE: Difficulties establishing VPN tunnel with IPNAT
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Difficulties establishing VPN tunnel with IPNAT
Perhaps, but I'v heard a lot of good things about IPF and IPNAT, especially since the nat is all in kernel where as natd is userland, so there is a slight performance boost possibly there as well.. It is not difficult to switch back to my old set up, but I thought I would give it a chance, since I'v not used IPF before I figured it was likely something I'v done wrong rather than something wrong with the program! I like the rule format in ipf and how simple it is to change ipnat rules on the fly without dumping current mappings. And it SHOULD work just as well as natd? On 25/11/2007, at 10:42 PM, Ted Mittelstaedt wrote: 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Difficulties establishing VPN tunnel with IPNAT
Jerahmy Pocott skrev: The Sonic Wall client doesn't trigger ANY firewall rules, which is why I thought there must be something going wrong with the NAT. It actually establishes the tunnel okay but never gets an IP address, from my understanding this client uses some sort of dhcp over ipsec to provision the client address.. What I am getting using the standard PPTP method are a bunch of hits: fxp1 @0:25 b x.x.x.x - 10.0.0.3 PR gre len 20 (93) IN NAT (rule @0:25 is the final 'block all' rule) What is protocol 'gre'? Why is a NAT'd packet getting blocked?! Thanks! J. On 25/11/2007, at 9:09 AM, Roger Olofsson wrote: 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
Re: Difficulties establishing VPN tunnel with IPNAT
On 26/11/2007, at 1:00 AM, Roger Olofsson wrote: Hello Jerahmy, (sorry for top-posting, btw). Gre is protocol 47. In your firewall rules you only allow/block protocols tcp/udp/icmp. If you want to use PPTP you will need to allow both the port and the protocol for it. I put: pass out quick on fxp1 proto gre from any to any keep state This allowed the PPTP connection to establish, how ever trying to use apps over that connection resulted in: fxp1 (block all rule) b x.x.x.x - 10.0.0.3 PR gre len 20 (53) (frag 57516:[EMAIL PROTECTED]) IN bad NAT By placing to rule: pass in quick on fxp1 proto gre from any to any and allowing frags everything started working properly, but allowing all gre traffic in doesn't seem like a good idea.. Is there any way to make this work without putting static ip address rules or allowing all traffic? In your original question you mentioned having problems with CVS. From the looks of it, you redirect CVS to 10.0.0.2, meaning that all users on that machine can use CVS. The redirect rule is supposed to redirect connections to CVS on the external interface to 10.0.0.2 on the internal lan, where the CVS server is actually running. Cheers, J. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
Jerahmy Pocott skrev: On 26/11/2007, at 1:00 AM, Roger Olofsson wrote: Hello Jerahmy, (sorry for top-posting, btw). Gre is protocol 47. In your firewall rules you only allow/block protocols tcp/udp/icmp. If you want to use PPTP you will need to allow both the port and the protocol for it. I put: pass out quick on fxp1 proto gre from any to any keep state This allowed the PPTP connection to establish, how ever trying to use apps over that connection resulted in: fxp1 (block all rule) b x.x.x.x - 10.0.0.3 PR gre len 20 (53) (frag 57516:[EMAIL PROTECTED]) IN bad NAT By placing to rule: pass in quick on fxp1 proto gre from any to any and allowing frags everything started working properly, but allowing all gre traffic in doesn't seem like a good idea.. Is there any way to make this work without putting static ip address rules or allowing all traffic? In your original question you mentioned having problems with CVS. From the looks of it, you redirect CVS to 10.0.0.2, meaning that all users on that machine can use CVS. The redirect rule is supposed to redirect connections to CVS on the external interface to 10.0.0.2 on the internal lan, where the CVS server is actually running. Cheers, J. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Hello Jerahmy, Some progress it seems? Why not set it to allow gre from VPN server only? Ie pass in quick on fxp1 proto gre from vpn server ip to any? The way you ask your question, 'make it work without static ip or allowing all traffic', isn't that contradictory? As for the frag part, I'd say that if gre needs frag, then you will have to enable it. About the CVS, I seem to have misunderstood your question. I assumed 10.0.0.2 wanted to recieve CVS inbound and not serve it outbound, or am I mistaking again? /Roger ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
On 26/11/2007, at 4:47 AM, Roger Olofsson wrote: Hello Jerahmy, Some progress it seems? Why not set it to allow gre from VPN server only? Ie pass in quick on fxp1 proto gre from vpn server ip to any? The way you ask your question, 'make it work without static ip or allowing all traffic', isn't that contradictory? As for the frag part, I'd say that if gre needs frag, then you will have to enable it. About the CVS, I seem to have misunderstood your question. I assumed 10.0.0.2 wanted to recieve CVS inbound and not serve it outbound, or am I mistaking again? /Roger Yes, that is what I meant by 'static ip' I could allow all gre from the specific ip address but I would prefer that gre traffic be allowed from a host only when an existing connection has been opened to it.. 10.0.0.2 is a CVS server. It seems to me that natd works better with ipsec ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
Jerahmy Pocott skrev: On 26/11/2007, at 4:47 AM, Roger Olofsson wrote: Hello Jerahmy, Some progress it seems? Why not set it to allow gre from VPN server only? Ie pass in quick on fxp1 proto gre from vpn server ip to any? The way you ask your question, 'make it work without static ip or allowing all traffic', isn't that contradictory? As for the frag part, I'd say that if gre needs frag, then you will have to enable it. About the CVS, I seem to have misunderstood your question. I assumed 10.0.0.2 wanted to recieve CVS inbound and not serve it outbound, or am I mistaking again? /Roger Yes, that is what I meant by 'static ip' I could allow all gre from the specific ip address but I would prefer that gre traffic be allowed from a host only when an existing connection has been opened to it.. 10.0.0.2 is a CVS server. It seems to me that natd works better with ipsec ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Hello again Jerahmy, It would seem that there is a PPTP proxy in ipf that you might want to try as well. The syntax would be: map fxp1 10.0.0.0/0 - 0/32 proxy port 1723 pptp/tcp Good luck! /Roger ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Difficulties establishing VPN tunnel with IPNAT
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 [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
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 [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
Sorry, the issue is connecting TO any out side VPN, not connecting from outside. I tested with ipf set to accept all and it still failed, so I figured it must be ipnat.. I had no issues when using ipfw/natd. 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- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difficulties establishing VPN tunnel with IPNAT
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- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
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
