Thanks for your replay, Trevor! Yes, indeed, PF was the case here. Except "pass on enc0 from any to any keep state (if-bound)", I also decided to pass all ESP traffic.
Tunnel, however, sometimes times out. Not sure about the reason for this yet. //maxim On Oct 14, 2011, at 9:24 PM, Trevor Benson wrote: > On Oct 14, 2011, at 5:27 AM, Maxim Bourmistrov wrote: > >> Hi all, >> problem is still there. >> >> Both sides are -current now (Oct 6 build). >> >> Any ideas what is wrong? >> >> //maxim >> > > Have you looked at your pf ruleset on both sides of the tunnel? Are you using blanket allow rules for ipsec traffic? E.G. "pass on enc0 from any to any"? or are you making more explicit rules to match your flows? Almost sounds like a state is not being created until a packet comes in from the other side, which can easily be tied to pf rules regarding your VPN tunnels. If you have explicit rulesets allowing traffic for VPN's my first guess is one side is missing the new rules that match the flows, or the network was not added to a macro or table being used in your pf ruleset. > > If you allow 'any to any' traffic via enc0 the next step I usually take is to tcpdump traffic on the local firewall for the enc0 and egress interfaces. have seen in the past pf rules not implemented properly for NAT & IPSec relabel a packet that should go over a VPN tunnel which may cause the other side to deny it, or to return traffic to the wrong IP, or to not match the remote firewall ESP ruleset and be accepted and decrypted. This causes what looks like a failure in traffic between endpoints, however it is a failure in rulesets causing problems with functional endpoints. Sending traffic from the reverse side could create a state that allows traffic to pass until the state is cleared. Much of this is from historic troubleshooting around OpenBSD 3.7-4.3, so changes in routing and handling encrypted traffic could make some of what I said currently inaccurate. Using tcpdump however on the egress, enc0 and possibly the ingress interfaces should give you a much better understanding of what is happening to the packets, and why the far side appears to deny the traffic. > > Trevor
