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
