Date: Mon, 10 Feb 2003 09:30:00 +0100 From: Borja Marcos <borjamar@sarenet.es> To: Peter Haight <peterh@sapros.com> Cc: freebsd-stable@freebsd.org Subject: Re: IPSEC problems after upgrade Message-ID: <200302100930.01219.borjamar@sarenet.es> In-Reply-To: <200302080922.h189MVM7007640@i19-069.us.catvmics.ne.jp> References: <200302080922.h189MVM7007640@i19-069.us.catvmics.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 08 February 2003 10:22, Peter Haight wrote: > I figured out what the problem was, so I thought I'd post the solution > because I never found it when I was searching the archives. Basically, > there was a change to the way IPSEC worked and the end result is that > the packets get run through the firewall after they get decrypted and s= o > they look like they are coming from an internal network on an external > interface and so they get rejected by a firewall rule that was rejectin= g > private network ip addresses. =09Hello, =09I am using IPSec to secure the traffic in a wireless network, and I ha= d=20 the firewall rules for the wireless interface (wi0) configured so that it= =20 would *only* accept IKE and ESP traffic. =09After upgrading to -STABLE my setup stopped working due to the behavio= r=20 change in ipfw; decrypted packets were passed again to IPFW. =09After a suggestion I read in this list, I tried IPFW2 using "layer2"=20 rules. It works, but I found some quirks.=20 =09My new setup is: # This rule *permits* ARP. add 190 allow ip from any to any layer2 mac-type 0x0806 via wi0 # 1: IKE add 200 allow udp from 192.168.2.0/24 500 to me 500 recv wi0 layer2 add 210 allow udp from me 500 to 192.168.2.0/24 500 xmit wi0 layer2 # 2: ESP add 300 allow esp from 192.168.2.0/24 to me recv wi0 layer2 add 310 allow esp from me to 192.168.2.0/24 xmit wi0 layer2 # After this, I had a problem: traffic *coming* from wi0 could not be sen= t=20 # via fxp0 because it seems that it was passed to ipfw2 gain before being # sent. Adding this rule fixed the problem. add 340 allow all from any to any via fxp0 layer2 # Now we deny unwanted traffic (remember, "layer2" through wi0) # This had an unwanetd side-effect; traffic received from the tunnel coul= d=20 # not be sent because it was apparently "labelled" as "coming from wi0" b= y=20 # ipfw, and it was checked again when sending the packets via fxp0, despi= te=20 # the fact that the rule specified "wi0". After I added rule 340 it=20 # worked. add 400 deny log all from any to 192.168.2.2 xmit wi0 layer2 add 410 deny log all from 192.168.2.2 to any recv wi0 layer2 # These two rules permit traffic from/through the encrypted tunnel. add 400 deny log all from any to 192.168.2.2 xmit wi0 layer2 add 410 deny log all from 192.168.2.2 to any recv wi0 layer2 =09Summarizing: =09I think ipfw2 is much superior to ipfw. The ability to work with layer= 2=20 rules is really great. However, I think configuration is tricky. And I am= =20 puzzled by the apparent confusion with the interfaces (see rules 340, 400= =20 and 410). Is this a bug? =09Regards, =09Borja. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302100930.01219.borjamar>