Rickard Borgm�ster wrote: >>It looks like the OpenBSD IPsec implementation integrates IPsec tunnel >>mode SAs with the routing table (good!) FreeBSD's KAME doesn't (yet; >>more recent KAME SNAPs have "device sec" which looks promising). > > > KAME? Is KAME something I need? The only thing I've added is > options IPSEC > options IPSEC_ESP > to my kernel and installed the isakmpd port. Then, of course, set up the > /etc/isakmpd/isakmpd.conf file.
No, there is an (older) KAME included in FreeBSD; however that one doesn't yet represent SAs in the routing table as interfaces. >>I bet your boxes pick the wrong source address when you generate packets >>on them to go to the other net, because you don't have any interfaces >>configured on these nets (IPsec SAs aren't interfaces, at least on >>FreeBSD). Try tcpdumping and tell me what you get. > > > Not sure I get your point here. Why do I don't have any interface on > these nets? Do you mean that on the FreeBSD box with: > pub-ip: 130.236.218.63 > priv-net: 192.168.2.0/24 > > ...that I miss an interface with 10.0.0.x address here? Sorry for being unclear: You miss a route entry (on the FreeBSD box, e.g.) that tells it to forward 10/24 to the OpenBSD box. You can't have such a route, because the SA that connects the two isn't represented in the routing table (it's a packet filter). > Well, tcpdump on the OpenBSD box, while pinging 10.0.0.1 from FBSD, > gives nothing. No packets received. tcpdumping output on FBSD while > pinging 10.0.0.1: > tcpdump: listening on xl0 > 23:08:31.194401 0:1:2:fa:aa:76 0:0:c:7:ac:29 0800 98: 130.236.218.63 > > 10.0.0.1: icmp: echo request It sends a packet 130.236.218.63->10.0.0.1, which isn't matched by the SAs (I assume, what do they say?) Note that the source here is your PHYSICAL IP address, and the destination is in the VIRTUAL network. This is why things break - your SAs don't match that. Thus, default route is used and the packet goes off into the Internet. Eventually, you get an "ICMP Host Unreachable" from this guy: > I also get a message (from where I don't know...) like this: > PING 10.0.0.1 (10.0.0.1): 56 data bytes > 36 bytes from linkoping-2-FE1-0-0.sunet.se (130.242.201.73): Destination > Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src > Dst 4 5 00 5400 cf42 0 0000 3d 01 473a 130.236.218.63 10.0.0.1 > Thing is, that both machines works just fine as IPSec peers, but not > "nodes" or what to call it. The passing the ESP packets just fine, and > connects their private/nat:ed networks to eachother. So the *BSD serves > their clients just fine, but cannot use the tunnel themselves... Yes, the problem only occurs with packet originating on the security gateways, because transit packets have the correct source addresses (check with tcpdump if you like). Only stuff originating on the gateways has this problem. Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
