Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

VPNmonitor with anti-spoofing is restricting a VPN tunnel from recovering after an outage.

0

0

Article ID: KB15267 KB Last Updated: 21 Sep 2009Version: 1.0
Summary:
Configuring VPNmonitor with Trust-side addressing in combination with anti-spoofing can cause a link to become unrecoverable - but there is a workaround.

Symptoms:
In a scenario similar to that described below, a customer had enabled anti-spoof screening protection on all zones (including tunnel traffic), and had VPNmonitoring enabled using Trust-to-Trust addressing. Initially, the tunnels would connect okay, but after a link outage sufficient for the VPNmonitor status at each end to go down, the ip-spoof protection would block the incoming VPNmonitor packets from reaching their target. And so, the VPN was unable to recover.

Consider the following topology..

topology diagram


The configurations are, for the most part, the same at each site; so I have listed the relevant config from Site-A only..

set zone untrust screen ...
set zone trust screen ip-spoof
set zone trust screen ip-spoof drop-no-rpf-route
set zone trust screen on-tunnel set interface e0/0 zone untrust set interface e0/1 zone trust set interface t.1 zone trust set interface e0/0 ip <public-ip> set interface e0/1 ip 192.168.1.1/24 set interface t.1 ip 10.10.10.1/24 set ike gateway ... set vpn to-site-b ... set vpn to-site-b bind interface t.1 set vpn to-site-b monitor source-interface e0/1 destination-ip 192.168.2.1
set vpn to-site-c ... set vpn to-site-c bind interface t.1 set vpn to-site-c monitor source-interface e0/1 destination-ip 192.168.3.1 set interface t.1 nhtb 10.10.10.2 vpn to-site-b set interface t.1 nhtb 10.10.10.3 vpn to-site-c set route 192.168.2.0/24 interface tunnel.1 gateway 10.10.10.2 set route 192.168.3.0/24 interface tunnel.1 gateway 10.10.10.3



Now, imagine an outage in the link between, say, Site-A and Site-C. We then see the following condition..

Site-A
1. The VPN to Site-C is marked as Down.
2. The route to Site-C is marked Inactive in the route table.

Site-C
1. The VPN to Site-A is marked as Down.
2. The route to Site-A is marked Inactive in the route table.



Let's assume Site-A is first to send the next VPNmonitor ping packet after the link is re-established. We see the following sequence..

1. The VPNmonitor ping packet (192.168.1.1 -> 192.168.3.1) is sent into the tunnel at Site-A and successfully reaches the remote firewall at Site-C.
2. As the ping packet is decrypted and processed at Site-C, the ip-spoofing option causes a reverse-route lookup for source 192.168.1.1.
3. Since Site-C does not yet recognise the tunnel as up, there is no valid route back to 192.168.1.1 (it is currently flagged inactive), and so the incoming ping packet is dropped as an ip-spoof packet.
4. Site-C does not send a ping-reply, so Site-A can not yet mark the VPN to Site-C as active, and so it can not mark the route to Site-C as active.
5. Site-C then sends its own VPNmonitor ping to Site-A, but for the same reasons this, too, is dropped as an ip-spoof packet at Site-A.



Each site needs the other end to come up first, which is not possible, so the result is a stalemate!

Solution:
Removing any of a number of the security settings could circumvent this problem - eg. not enabling ip-spoof protection on the Trust zone, not enabling ip-spoof protection for tunnel traffic on the Trust zone, or even changing the VPNmonitor to use Untrust-side addressing (so that inactive routes will have no effect on received VPNmonitor packets); however none of these were desired.

The root-cause of this problem is route-table related, so an always-up route needs to be added to override the anti-spoofing - essentially, pinholing the ip-spoof protection. The following host-route was added to each end (although at only one end would be enough) to resolve..
set route 192.168.3.1/32 interface tunnel.1 gate 10.10.10.3 permanent

The "permanent" option allows the route to remain active even when the monitoring is Down. This then allows the ip-spoof protection to permit the incoming monitor packet from the remote end.
On receiving the ping-reply, the remote end can then re-activate its own tunnel routes, and likewise permit incoming monitor pings from this end.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search