![]() ![]() In order to resolve this, I had to configure both Dead-Peer-Detection and Juniper’s VPN monitoring on both sides of the connection – so that each SRX would more actively monitor the tunnel status. Clear the stale IPSec security association, and the tunnels re-establish immediately. Even more weird, whenever the issue occurred – one of the two SRX clusters would always still show the IPSec tunnel as up, while the peer SRX would just keep logging errors about bad SPIs. This seemed a bit weird to me, because the re-key interval was set for 8 hours – which means that re-key wasn’t playing into this. Then they would drop and not re-establish for 2-4 hours. The initial issue seemed to be that the VPNs would establish, but only for about 2-4 hours. Strangely enough, when I began migrating tunnels to the new cluster we started to see the VPNs to remote SRXs drop sporadically. The first remote sites to migrate were less of a priority to keep connectivity established, so I took this opportunity to spend a little time figuring out what was going on. I had at least half a dozen of these devices interconnected with full mesh VPNs, and experienced no issues. However, when I picked up a new set of SRX 1500s a few months back, Juniper had just released 15.1X49-D70.3 – so I upgraded before these were put into production. The original SRXs that I installed were running JunOS 15.1X49-D40.6. ![]() Issue #2 – VPN drops every 2-4 hours and doesn’t re-establish for another 2-4 hours (or manual SA clearing) Even though I’m using an unnumbered tunnel interface, this command still needs to exist to tell the SRX that the interface is used for IPv4 traffic. Under the st0 configuration, unit 1 (or whichever tunnel interface you might be using) needs to have “ family inet” configured. The config on both sides practically matched, but there was one thing missing that was preventing the tunnel from passing traffic. Pre-shared-key ascii-text xxxxxxxxx # SECRET-DATA For reference, here is what the config looked like: > show configuration security ike I had a set of VPN tunnels between two locations that were not passing traffic, even though a “ show security ipsec sa” showed the tunnels as established. So each VPN is configured with a “ set security ipsec vpn vpn_name bind-interface st0.x” command. All of our tunnels are route-based, using secure tunnel interfaces. This one initially took me a minute to figure out. Issue #1 – VPN is up, but no traffic is flowing across it This is still an on-going process – but I wanted to throw out some of the issues I’ve run into so far, and what I’ve been able to do to fix them or work around them. Today each SRX cluster has around 15 different VPN peers, which are made up of other SRXs, older SSGs, CheckPoint firewalls, Cisco ASAs, and Watchguard firewalls. ![]() We run multiple locations around the world, and unfortunately have to keep full mesh VPN connectivity due to the way our systems have been deployed. (Oh, and the fact that pre-15.1X49-D60 doesn’t support In-service-upgrades – but don’t get me started on that one…) Some have been completely new installs for a new location and some have been migrations from other devices… But while most of the process has been surprisingly smooth – there is one thing that keeps coming back up: VPN issues. So far I’ve had the opportunity to install ten SRX 1500s, six SRX 345s, and one SRX 340. After a few months, I’ve honestly really started to enjoy working with them – so much that we’ve decided to start standardizing our firewall platforms by ditching everything else. Last year we began migrating from our old Juniper SSG firewalls to the new SRX line. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |