Re: NAT over enc(4)
Hello Mitja, Le 05/02/2013 22:36, Mitja Muženič a écrit : I'm the author of the article you quoted. Your article is really great, I'm glad to get some help from you :) Do you have a default gateway? IPsec on OpenBSD behaves weirdly if you don't have one (even if it's not needed!). This scenario is likely to happen especially in the test setups with directly connected firewalls... Yes, I have one. In fact this is not a lab setup. I'm doing the test in production environment. I can break it as this is not a site of great importance. The two sites are connected via the Internet. The trick is that both ipsec tunnel perform a sanity check on the address range of the traffic. On this side the tunnel is between 192.168.0/24 and 192.168.6/24 [1], but we tell the peer that he ought to establish a tunnel from _his_ 192.168.0/24 to 192.168.7/24 [2]. So your traffic from the remote 192.168.0.1 to 192.168.7.1 fails the source check on this end, as there is no NAT on remote device and this side sees traffic from 192.168.0.1, not 192.168.6.1 as defined by the tunnel [1], so it's silently discarded. If you try to bypass this by pinging from 192.168.6.1 to 192.168.7.1, such traffic won't match the remote site's source tunnel definition [2] and will be dropped on the remote end already before even entering the tunnel. It isn't clear to me. There is NAT on remote the device and I can see traffic from 192.168.6.1. There shouldn't be any traffic from 192.168.x.0 on your em0, that's your public interface, isn't it? I presume this comes from you actually testing this in a lab and em0 is actually directly connected to the remote device? So the private traffic on em0 is leakage from far side because that traffic does not enter the vpn tunnel at all. em0 is my public facing interface and it is connected to an ISP that route traffic to the other site. This is unexpected, you should be seeing icmp echo from 192.168.7.1 to 192.168.6.1. Double check that your "match on enc0..." rules really apply to those packets, I've been bitten by the "match" logic before. For test purposes you can always rewrite that rule to "pass out quick on enc0...". Also see that you don't have a "set skip on enc0" line. I don't for sure. The whole pf.conf was posted at the top of the first mail. There is nothing more than the first "match" rule. I'm pretty sure the problem lies with PF, can't see where for now but I'm still searching. Thank you very much for the answer. Denis
NAT over enc(4)
Hello all, I'm trying to build an IPSec VPN between two sites and both sites are using the same addressing plan. I'm using OpenBSD 5.1 on a Soekris board on one site and a closed-source appliance on the other end. I remembered an old article on undeadly.org (http://undeadly.org/cgi?action=article&sid=20090127205841) and tried to adapt but without luck so far. I need a 1:1 NAT mapping as multiple servers must be accessible from either site. Here is my setup (public IP and PSK changed) : * /etc/ipsec.conf : 8<--- ike esp from 192.168.7.0/24 (192.168.0.0/24) to 192.168.6.0/24 peer 8.8.8.8 main auth hmac-sha1 enc aes-256 group modp1024 quick auth hmac-sha1 enc aes-256 group modp1024 psk "mypsk" 8<--- * /etc/pf.conf : 8<--- match on enc0 from 192.168.0.0/24 to 192.168.6.0/24 binat-to 192.168.7.0/24 source-hash 8<--- * pfctl -sr : 8<--- match out on enc0 inet from 192.168.0.0/24 to 192.168.6.0/24 nat-to 192.168.7.0/24 source-hash 0xa28e791d2929a414834ebd15872704fa static-port match in on enc0 inet from 192.168.6.0/24 to 192.168.7.0/24 rdr-to 192.168.0.0/24 source-hash 0xa28e791d2929a414834ebd15872704fa 8<--- * ifconfig : 8<--- em0: flags=8843 mtu 1500 lladdr 00:00:24:ce:b9:34 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::200:24ff:fece:b934%em0 prefixlen 64 scopeid 0x1 inet 8.8.4.4 netmask 0xff00 broadcast 8.8.4.254 em1: flags=8843 mtu 1500 lladdr 00:00:24:ce:b9:35 priority: 0 media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active inet6 fe80::200:24ff:fece:b935%em1 prefixlen 64 scopeid 0x2 inet 192.168.0.180 netmask 0xff00 broadcast 192.168.0.255 8<--- * route -n show -encap 8<--- Routing tables Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.6/24 0 192.168.0/24 0 0 8.8.8.8/esp/use/in 192.168.0/24 0 192.168.6/24 0 0 8.8.8.8/esp/require/out 8<--- My local and remote net is 192.168.0.0/24 and forwarding is enabled. I can see the IPSec tunnel is up and the routes are set. If I ping from the remote site to the site behind the OpenBSD router (ping 192.168.7.1 from 192.168.0.1 for example), I can see from a tcpdump session that icmp echo from 192.168.6.1 to 192.168.7.1 appears on em0 and dies there. Nothing pass on em1. On the other hand, if I ping from the OpenBSD site to the other side (ping 192.168.6.1 from 192.168.0.1 for example), I can see on enc0 a trace of icmp echo from 192.168.0.1 to 192.168.6.1 (and not from 192.168.7.1 to 192.168.6.1 as one might expect). What did I miss ? In undeadly.org's article it is stated that you need both routers to be OpenBSD. I understand that but still want to believe I should see some trafic on em1, don't you think so ? Thank you in advance, Denis
