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>
index | next in thread | previous in thread | raw e-mail
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 so > 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 rejecting > private network ip addresses. Hello, I am using IPSec to secure the traffic in a wireless network, and I had the firewall rules for the wireless interface (wi0) configured so that it would *only* accept IKE and ESP traffic. After upgrading to -STABLE my setup stopped working due to the behavior change in ipfw; decrypted packets were passed again to IPFW. After a suggestion I read in this list, I tried IPFW2 using "layer2" rules. It works, but I found some quirks. My 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 sent # 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 could # not be sent because it was apparently "labelled" as "coming from wi0" by # ipfw, and it was checked again when sending the packets via fxp0, despite # the fact that the rule specified "wi0". After I added rule 340 it # 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 Summarizing: I think ipfw2 is much superior to ipfw. The ability to work with layer2 rules is really great. However, I think configuration is tricky. And I am puzzled by the apparent confusion with the interfaces (see rules 340, 400 and 410). Is this a bug? Regards, Borja. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302100930.01219.borjamar>