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 need a 1:1 NAT mapping as multiple servers must be accessible from
Here is my setup (public IP and PSK changed) :
* /etc/ipsec.conf :
ike esp from 192.168.7.0/24 (192.168.0.0/24) to 192.168.6.0/24 peer
126.96.36.199 main auth hmac-sha1 enc aes-256 group modp1024 quick auth
hmac-sha1 enc aes-256 group modp1024 psk "mypsk"
* /etc/pf.conf :
match on enc0 from 192.168.0.0/24 to 192.168.6.0/24 binat-to
* pfctl -sr :
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
* route -n show -encap
Source Port Destination Port Proto
192.168.6/24 0 192.168.0/24 0 0 188.8.131.52/esp/use/in
192.168.0/24 0 192.168.6/24 0 0
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 ?
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 , but we tell the peer that he ought to establish a tunnel
> from _his_ 192.168.0/24 to 192.168.7/24 . 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 , 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  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.