IPSec ESP packets dropped by default security policy rule after reboot

MrShady
MrShady Posts: 3  Freshman Member
First Comment
in Security

This seems like pretty odd behavior. A site-to-site VPN, IKeV2, pre-shared key, local and remote policies are /24 networks, defined in the IPSec_VPN zone.

On boot, the tunnel automatically connects but won't pass traffic.

If I disable the security policy it will start passing traffic. If I re-enable the security policy it continues to pass traffic. This can also be achieved by changing the default policy to allow then back to deny. Once either is done, the tunnel will work until the next reboot, including across VPN disconnects and reconnects.

I did a Routing Trace and it showed ESP packets from the remote endpoint to the local endpoint, from/to VPN ID = 0, incoming interface wan1, "The packet was dropped by Firewall". Enabling security policy logging shows it was dropped by the default rule.

I have a second tunnel setup the same way (same local policy, different remote policy, different local and remote ids) that connects and works on boot. If could possibly matter, the broken tunnel is tunnel 1 and the working tunnel is tunnel 2 on the VPN Connection and VPN Gateway tabs.

The router is a zyxel usg flex 200 with the latest firmware (5.39(ABUI.0)). The tunnels are new, so created on this firmware release. The remote endpoints are zywall 110's on the latest firmware (4.73(AAAA.2)).

My workaround so far was to add a security policy rule allowing ESP traffic from the WAN zone to the ZyWALL zone from the remote endpoints to the local wan1 address.

This, of course, shouldn't be necessary.

This allows traffic to flow through the tunnel without intervention, after a reboot. Inactivating the rule after boot does not affect traffic. Of course I'm leaving it active so I don't have to intervene in case of a reboot.

Accepted Solution

  • PeterUK
    PeterUK Posts: 3,461  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary
    edited September 12 Answer ✓

    I think I posted something like this under a case where the nailed up end needed WAN to zywall even when Zywall will be outgoing and is allowed it should map the inbound from outbound

    is that what your seeing? other then that you need WAN to Zywall for VPN to work

All Replies

  • PeterUK
    PeterUK Posts: 3,461  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary
    edited September 12 Answer ✓

    I think I posted something like this under a case where the nailed up end needed WAN to zywall even when Zywall will be outgoing and is allowed it should map the inbound from outbound

    is that what your seeing? other then that you need WAN to Zywall for VPN to work

  • MrShady
    MrShady Posts: 3  Freshman Member
    First Comment

    In my case both ends of the tunnels are "nailed up". Based on your comments and , I think, the post you maybe referenced, it got me looking.

    The problem was I didn't have the WAN_to_Device built in rule activated, which allows the ESP traffic. It is enabled on the remote routers. On the tunnel that works at boot, there is another policy that has the effect of passing ESP traffic (passes all from the remote IP) so that tunnel did not show the problem.

    Unanswered, I think, is why the tunnel works once a policy passing ESP traffic is enabled, even if immediately disabled. I assume something with UDP session stuff. I did try deactivating the balky tunnel at each end and insuring that all sessions were expired. When activated the tunnel would immediately connect and pass traffic. Not going to worry further about it.

    The final solution will be to leave WAN_to_Device inactive but copy it and add my Source and Destination settings.

    Thank you for the quick help. The router is due to go into service in the next week or so.

Categories

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）