Date: Fri, 4 May 2001 16:37:01 -0700 From: steve@Watt.COM (Steve Watt) To: questions@freebsd.org Cc: flemming@froekjaer.org Subject: Re: ipsec/ipfw combination insecure? Message-ID: <200105042337.f44Nb1k98320@wattres.Watt.COM> In-Reply-To: <989018541-m2n-gw@Watt.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
flemming@froekjaer@org wrote: >When using ipsec to set up a VPN, address translation is taking place >before ipfw gets the packets. This means that ipfw sees the packets from >the remote RFC1918 network as coming from the external network >interface, and thus one is forced to bore a gaping hole for incoming >traffic in that IP range for the VPN to work. As far as I know, hackers >can easily spoof their IP, so it will look like their packets are coming >from that very same IP range. Am I too paranoid here, or is there really >a security problem with this? If there is, what can be done about it? If >there isn't, why not? It certainly appears insecure to me, as well. I fixed it by adding RFC1918 filters to the router outside my FreeBSD box, but that seems distasteful. Unfortunately, architecting a fix seems difficult; I would guess that the ingress side would have to be trained such that if the source address was one that could come in via an IPsec tunnel, it should be dropped. Except that the drop needs to happen before IPsec processing, and IPsec processing simply returns the incoming packet to the interface queue. I think the best choice would be to force the post-IPsec packets to appear as if they came from a different interface. It's an ugly problem. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105042337.f44Nb1k98320>