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
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: 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
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 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]"
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 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 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 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 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: 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 '. 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:
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 o
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
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 '. 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
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 '. 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 r
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 > >
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 '. 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
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 '. 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, 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 '. 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 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 "[EMAIL PROTECTED]" ___ 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: Kernel Panic when using mpd VPN Tunnel
On Thursday 04 May 2006 15:52, Shawn Guillemette wrote: > Hello all, > > > > > > I have a Digital AlphaPC 164LX 533 MHz, running FreeBSD > 4.11-RELEASE > > I have installed /usr/ports/net/mpd and attempted to make a vpn connection What kind of VPN? mpd does ppp over serial lines, ethernet, udp and pptp. > and after authenticating it seems to bring the machine to a panic with the > following info in the messages file. > > > > May 3 17:20:35 medusa /kernel: > > May 3 17:20:35 medusa /kernel: fatal kernel trap: > > May 3 17:20:35 medusa /kernel: > > May 3 17:20:35 medusa /kernel: trap entry = 0x4 (unaligned access fault) > > May 3 17:20:35 medusa /kernel: a0 = 0xfe5cb5ce > > May 3 17:20:35 medusa /kernel: a1 = 0x28 > > May 3 17:20:35 medusa /kernel: a2 = 0x1 > > May 3 17:20:35 medusa /kernel: pc = 0xfc4da0a0 > > May 3 17:20:35 medusa /kernel: ra = 0xfc4dabec > > May 3 17:20:35 medusa /kernel: curproc= 0xfe00098d6300 > > May 3 17:20:35 medusa /kernel: pid = 189, comm = mpd > > May 3 17:20:35 medusa /kernel: > > May 3 17:20:35 medusa /kernel: panic: trap > > May 3 17:20:35 medusa /kernel: > > > > > > Now the how to I was following asked that I make sure that the kernel is > compiled with the following device option. > > > > device tun # Packet tunnel. > I don't know how tun(4) is relevant > > > This line was in the kernel config but was listed as follows > > > > pseudo-device tun # Packet tunnel. > > > > > > I have tried using both versions and have seen the same kernel panic each > time. > > > > > > > > Any one have any tips for me? Describe what you want to do please. what kind of VPN and what the peers are. I am using mpd for a long time and never had a panic(well, almost) > > ___ > 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]"
Kernel Panic when using mpd VPN Tunnel
Hello all, I have a Digital AlphaPC 164LX 533 MHz, running FreeBSD 4.11-RELEASE I have installed /usr/ports/net/mpd and attempted to make a vpn connection and after authenticating it seems to bring the machine to a panic with the following info in the messages file. May 3 17:20:35 medusa /kernel: May 3 17:20:35 medusa /kernel: fatal kernel trap: May 3 17:20:35 medusa /kernel: May 3 17:20:35 medusa /kernel: trap entry = 0x4 (unaligned access fault) May 3 17:20:35 medusa /kernel: a0 = 0xfe5cb5ce May 3 17:20:35 medusa /kernel: a1 = 0x28 May 3 17:20:35 medusa /kernel: a2 = 0x1 May 3 17:20:35 medusa /kernel: pc = 0xfc4da0a0 May 3 17:20:35 medusa /kernel: ra = 0xfc4dabec May 3 17:20:35 medusa /kernel: curproc= 0xfe00098d6300 May 3 17:20:35 medusa /kernel: pid = 189, comm = mpd May 3 17:20:35 medusa /kernel: May 3 17:20:35 medusa /kernel: panic: trap May 3 17:20:35 medusa /kernel: Now the how to I was following asked that I make sure that the kernel is compiled with the following device option. device tun # Packet tunnel. This line was in the kernel config but was listed as follows pseudo-device tun # Packet tunnel. I have tried using both versions and have seen the same kernel panic each time. Any one have any tips for me? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Freebsd to Sonicwall vpn tunnel
I have been searching far and wide for working examples of a site-to-site vpn tunnel from a freebsd firewall to a sonicwall appliance(Pro 2040). I can't even seem to make it work with it using anonymous in the racoon.conf, however, at some point I need it to use a specific sa for the sonicwall so tunnels connect using anon. Here are the errors I get from the various logs. From the sonicwall: IKE negotiation complete. Adding IPSec SA. (Phase 2) From racoon.log: 2006-01-11 14:21:38: INFO: isakmp.c:808:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 24.153.127.112[500]<=>12.96.91.86[500] 2006-01-11 14:21:38: INFO: isakmp.c:813:isakmp_ph1begin_i(): begin Identity Protection mode. 2006-01-11 14:21:38: INFO: isakmp.c:2459:log_ph1established(): ISAKMP-SA established freebsd-ip[500]-sonicwall-ip[500] spi:960f1f7cdc88e2ac:b89856165f09f180 2006-01-11 14:21:39: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: freebsd-ip[0]<=>sonicwall-ip[0] 2006-01-11 14:21:39: ERROR: isakmp_inf.c:843:isakmp_info_recv_n(): unknown notify message, no phase2 handle found. 2006-01-11 14:21:54: ERROR: pfkey.c:804:pfkey_timeover(): sonicwall-ip give up to get IPsec-SA due to time up to wait. 2006-01-11 14:22:05: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: freebsd-ip[0]<=>sonicwall-ip[0] 2006-01-11 14:22:05: ERROR: isakmp_inf.c:843:isakmp_info_recv_n(): unknown notify message, no phase2 handle found. I have working tunnels from the sonicwall to other sonicwall. I also have working tunnels from the freebsd box to other freebsd machines. Has anyone else done what I'm trying to do successfully? Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VPN Tunnel
[EMAIL PROTECTED] wrote: > I'm having some problems getting a VPN tunnel working between two sites. > Currently I am just trying to establish a tunnel and worry about the > encryption after the tunnel is up and functional, however I cannot even get > the tunnel established. I have followed the directions from the FreeBSD > handbook but had no luck. Here is my scenario: > > Network 1: > > FreeBSD Internal IP: 192.168.20.13 > FreeBSD External IP: 12.34.56.78 > > Network 2: > > FreeBSD Internal IP: 192.168.15.2 > FreeBSD External IP: 87.65.43.21 > > On the Network 1 Box, I configured the gif0 interface as follows: > > [EMAIL PROTECTED] ifconfig gif0 create > [EMAIL PROTECTED] ifconfig gif0 tunnel 12.34.56.78 87.65.43.21 > [EMAIL PROTECTED] ifconfig gif0 inet 192.168.20.13 192.168.15.2 netmask > 255.255.255.255 > > For IPFilter, I have the following rules at the TOP of the script: > pass in quick from 87.65.43.21 to any on xl0 > pass in quick on gif0 all > pass out quick on gif0 all > > On the Network 2 Box, I configured the gif0 interface as follows: > > [EMAIL PROTECTED] ifconfig gif0 create > [EMAIL PROTECTED] ifconfig gif0 tunnel 87.65.43.21 12.34.56.78 > [EMAIL PROTECTED] ifconfig gif0 inet 192.168.15.2 192.168.20.13 netmask > 255.255.255.255 > > For IPFilter, I have the following rules at the TOP of the script: > pass in quick from 12.34.56.78 to any on xl0 > pass in quick on gif0 all > pass out quick on gif0 all > > After I have created both gif0 interfaces on each of the boxes, the FreeBSD > handbook says I should be able to ping the private IP of the other BSD > machine. When I ping from Network 1, I don't get any type of response and > just 100% failed sent packets. When I ping from Network 2, I get a 'No route > to host' message as well as 100% failed sent packets. > > I have been at this for 2 days now and I'm really starting to get frustrated. > > Am I missing something here? Any help would be appreciated. Looks like the routing table in network 2 doesn't work. netstat -rn should give you a clue what's wrong. Fabian -- http://www.fabiankeil.de/ pgp3YPQP8sO6A.pgp Description: PGP signature
VPN Tunnel
Hey everyone.. I'm having some problems getting a VPN tunnel working between two sites. Currently I am just trying to establish a tunnel and worry about the encryption after the tunnel is up and functional, however I cannot even get the tunnel established. I have followed the directions from the FreeBSD handbook but had no luck. Here is my scenario: Network 1: FreeBSD Internal IP: 192.168.20.13 FreeBSD External IP: 12.34.56.78 Network 2: FreeBSD Internal IP: 192.168.15.2 FreeBSD External IP: 87.65.43.21 On the Network 1 Box, I configured the gif0 interface as follows: [EMAIL PROTECTED] ifconfig gif0 create [EMAIL PROTECTED] ifconfig gif0 tunnel 12.34.56.78 87.65.43.21 [EMAIL PROTECTED] ifconfig gif0 inet 192.168.20.13 192.168.15.2 netmask 255.255.255.255 For IPFilter, I have the following rules at the TOP of the script: pass in quick from 87.65.43.21 to any on xl0 pass in quick on gif0 all pass out quick on gif0 all On the Network 2 Box, I configured the gif0 interface as follows: [EMAIL PROTECTED] ifconfig gif0 create [EMAIL PROTECTED] ifconfig gif0 tunnel 87.65.43.21 12.34.56.78 [EMAIL PROTECTED] ifconfig gif0 inet 192.168.15.2 192.168.20.13 netmask 255.255.255.255 For IPFilter, I have the following rules at the TOP of the script: pass in quick from 12.34.56.78 to any on xl0 pass in quick on gif0 all pass out quick on gif0 all After I have created both gif0 interfaces on each of the boxes, the FreeBSD handbook says I should be able to ping the private IP of the other BSD machine. When I ping from Network 1, I don't get any type of response and just 100% failed sent packets. When I ping from Network 2, I get a 'No route to host' message as well as 100% failed sent packets. I have been at this for 2 days now and I'm really starting to get frustrated. Am I missing something here? Any help would be appreciated. --Tim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
multible networks routing over vpn tunnel
hello, i have two private network segments, 192.168.0.x and 192.168.1.x connected over a VPN Tunnel, freebsd, racoon and ipsec. on one site we want to add a new network segment 192.168.3.x is this possible and how is the correct syntax ? this is what i have done: gifconfig gif0 A.B.C.D W.X.Y.Z ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 255.255.255.0 # gifconfig gif0 gif0: flags=8011 mtu 1280 inet 192.168.0.1 --> 192.168.1.1 netmask 0x physical address inet A.B.C.D --> W.X.Y.Z regards thomas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd vpn tunnel with two subnets on one site
Hi, i have created a vpn tunnel between two freebsd 5.3 machines with ipsec and racoon. Iam routing two private networks behind the vpn gateways over the internet. Its working fine. 192.168.0.0 / 24 | | VPN Gateway 1 | | Internet | | VPN Gateway 2 | | 192.168.1.0 / 24 If I now want to add a new network on one site for example 192.168.2.0 / 24, how can I do this ? Is this a routing problem, or is ipsec limited to route only one network ? Thanx for your answers . ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VPN Tunnel Routing
Greetings: I am trying to construct a "B2B" mode VPN tunnel between my house and my work using FreeBSD. My work uses Checkpoint VPN-1 and I have a FreeBSD firewall that is running ipfilter to do firewall/NAT duties. I have so far been successful in creating a tunnel between the FreeBSD box and my work VPN server using /usr/ports/security/racoon, gif (4), and the IPSEC kernel module. I am able to establish a tunnel and pass packets from my FreeBSD firewall to my work network. I have not been able to pass packets from the rest of my home network to my work over the VPN tunnel. The packets seem to never make it into the tunnel, and also do not pass out to the Internet via my firewall. Here is my current configuration (IPs changed to protect the guilty): fxp0: flags=8843 mtu 1500 inet6 fe80::2a0:c9ff:fe5c:c37b%fxp0 prefixlen 64 scopeid 0x1 inet 100.100.100.1 netmask 0xff00 broadcast 68.3.250.255 ether 00:a0:c9:5c:c3:7b media: Ethernet autoselect (10baseT/UTP) status: active fxp1: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::2a0:c9ff:fe76:4764%fxp1 prefixlen 64 scopeid 0x2 ether 00:a0:c9:76:47:64 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 faith0: flags=8002 mtu 1500 gif0: flags=8051 mtu 1280 tunnel inet 68.3.250.5 --> 199.64.13.20 inet6 fe80::2a0:c9ff:fe5c:c37b%gif0 prefixlen 64 scopeid 0x5 inet 192.168.0.1 --> 200.200.200.1 netmask 0xff00 fxp0 is my external network adapter, connected to the Internet and assigned "100.100.100.1" by my ISP. gif0 is the tunnel adapter and ties my network to my work's network. The ip 200.200.200.1 is the inside interface of my work's VPN server. The commands used to create the gif tunnel are as follows: ifconfig gif0 create tunnel 100.100.100.1 200.200.201.1 ifconfig gif0 inet 192.168.0.1 200.200.200.1 netmask 255.255.255.0 100.100.100.1 is my external address again 200.200.201.1 is the external interface on my work's VPN server 200.200.200.1 is the internal interface on my works VPN server again As you can see, I am using the same IP for my internal interface on my firewall (fxp1) as I am for the local termination of the gif tunnel. I have also tried using a different IP address with the same results. As far as I can tell, the routing is set up correctly with all routes to my work's netowrk pointing at the gif tunnel (either 192.168.0.1 or 192.168.0.2depending on my configuration). I guess my main questions are: why aren't packets from my inside network entering the gif tunnel? Why is it that only packets that originate on the firewall itself seem to enter the gif tunnel? Is this fixable? If so how? Cheers, Ian Cartwright To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
VPN Tunnel Routing
Greetings: I am trying to construct a "B2B" mode VPN tunnel between my house and my work using FreeBSD. My work uses Checkpoint VPN-1 and I have a FreeBSD firewall that is running ipfilter to do firewall/NAT duties. I have so far been successful in creating a tunnel between the FreeBSD box and my work VPN server using /usr/ports/security/racoon, gif (4), and the IPSEC kernel module. I am able to establish a tunnel and pass packets from my FreeBSD firewall to my work network. I have not been able to pass packets from the rest of my home network to my work over the VPN tunnel. The packets seem to never make it into the tunnel, and also do not pass out to the Internet via my firewall. Here is my current configuration (IPs changed to protect the guilty): fxp0: flags=8843 mtu 1500 inet6 fe80::2a0:c9ff:fe5c:c37b%fxp0 prefixlen 64 scopeid 0x1 inet 100.100.100.1 netmask 0xff00 broadcast 68.3.250.255 ether 00:a0:c9:5c:c3:7b media: Ethernet autoselect (10baseT/UTP) status: active fxp1: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::2a0:c9ff:fe76:4764%fxp1 prefixlen 64 scopeid 0x2 ether 00:a0:c9:76:47:64 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 faith0: flags=8002 mtu 1500 gif0: flags=8051 mtu 1280 tunnel inet 68.3.250.5 --> 199.64.13.20 inet6 fe80::2a0:c9ff:fe5c:c37b%gif0 prefixlen 64 scopeid 0x5 inet 192.168.0.1 --> 200.200.200.1 netmask 0xff00 fxp0 is my external network adapter, connected to the Internet and assigned "100.100.100.1" by my ISP. gif0 is the tunnel adapter and ties my network to my work's network. The ip 200.200.200.1 is the inside interface of my work's VPN server. The commands used to create the gif tunnel are as follows: ifconfig gif0 create tunnel 100.100.100.1 200.200.201.1 ifconfig gif0 inet 192.168.0.1 200.200.200.1 netmask 255.255.255.0 100.100.100.1 is my external address again 200.200.201.1 is the external interface on my work's VPN server 200.200.200.1 is the internal interface on my works VPN server again As you can see, I am using the same IP for my internal interface on my firewall (fxp1) as I am for the local termination of the gif tunnel. I have also tried using a different IP address with the same results. As far as I can tell, the routing is set up correctly with all routes to my work's netowrk pointing at the gif tunnel (either 192.168.0.1 or 192.168.0.2depending on my configuration). I guess my main questions are: why aren't packets from my inside network entering the gif tunnel? Why is it that only packets that originate on the firewall itself seem to enter the gif tunnel? Is this fixable? If so how? Cheers, Ian Cartwright To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
