Setting up VPNs is always a PIA, but Juniper really dumbs it down and I have to say really spoiled me. So when it came time to setup another VPN with a partner who is running an ASA, I had to shake off the rust and think of what could go wrong. Most of the time I set up tunnels with non-Juniper devices, it ends up being a wrong proxy-id on either side. You can usually tell this when you see “DOI 1 18 INVALID-ID-INFORMATION” or “No policy exists for the proxy ID: local(local ip/netmask/0/0) remote(remote ip/netmask/0/0)”. ScreenOS derives the proxy-id from the tunnel, so I normally don’t worry about setting this up, but of course it only works as designed when you connect to other ScreenOS devices. I don’t know if the SRX platform behaves the same way since it’s running JunOS. I caught this error message and we managed to get the tunnel going, but no traffic was passing through. Being a Friday night and this not being a critical issue at the moment, both sides decided to come back to it later.
I have a couple Cisco routers and Juniper SSGs at home for a lab. I recently picked up an ASA 5505 off of eBay as well and decided to give the configuration on both sides a try to figure out what is going wrong. Beyond setting up AAA, ntp, and the rest of the management stuff, I have not really had time to do anything with the ASA. I have experience with IOS from a router and switch perspective, but I’ve never touched PIX. All of my firewall experience is with Fortinet, ScreenOS, and whatever linux distros I’ve tried (Astaro comes to mind).
Cisco’s documentation being as awesome as it is, that is the first place I went to figure out what to do:
I’m not one to use a GUI with Cisco devices, so I went through some configuration examples and the cli configuration guide as a first pass to get the tunnel up and running. I managed to do this, but I couldn’t connect anything beyond the inside interfaces on either gateway and only gateway to gateway.
So I wiped the ACLs and crypto config I put in and fired up ASDM. I used the IPSEC VPN Wizard and kept flipping back to my console to see what changes it was making. One of the first things that caught my eye was the option to “Enable inbound IPSEC sessions to bypass interface access list.” Not having experience with setting up Cisco VPNs before, I thought, “Why on God’s green Earth would I not have policies to control that traffic?” Yes, it’s implied that I trust the other side to some degree if I’m setting up a VPN tunnel, but I still want fine grain control of the communication. That checkbox leaves the default setting “sysopt connection permit-vpn” intact. This does exactly what the description says on the checkbox. Without it, you have to setup multiple ACLs to get tunnel traffic working properly because the traffic terminates on the outside interface of the ASA.
I setup a working VPN with and without that box checked, and I decided to go with it checked. As it turns out, you can use filters on the connection group policy to control exactly what passes through the tunnel. In this basic lab without the box checked, I had to add an additional 3 policies to get traffic moving through the tunnel. This might not seem like a hassle, but this is just a lab with a single site to site. Extrapolate that complexity when you start adding multiple sites. There may be some scenarios where filters just won’t be sufficient, but for what I need to do at work, they will accomplish the task.
Excerpt from Troubleshooting Guide:
Note: If you do not wish to use the sysopt connection command, then you must explicitly permit the required traffic, which is interesting traffic from source to destination, for example, from LAN of remote device to LAN of local device and “UDP port 500” for outside interface of remote device to outside interface of local device, in outside ACL.
http://networking-forum.com/viewtopic.php?f=35&t=3310
According to chapter 21 of The Complete Cisco VPN Configuration Guide, the way to do what I am asking is to write manual access lists to permit ipsec/isakmp traffic.
Using this method, one must manually write access lists to permit all ports used by ipsec/isakmp components to allow this traffic into a firewall. This method makes it so packets are checked against access lists twice: once when coming in as ipsec traffic, and again once decrypted as plaintext packets. This allows one to match only desired traffic using the second, more stringent access list.
The alternative is using the “sysopt connection permit-vpn” command. This is also known as ACL bypassing, hence, you cannot restrict traffic further, since the access lists are written for you using this command.
Another method (usable only for 7.0 and higher) is using the “sysopt connection permit-vpn” command on an outside interface, and writing more restrictive access lists outgoing on an inside interface. This method enables one to allow all ipsec/isakmp traffic into the firewall while restricting where the traffic can go from there.
The second thing that caught my eye was a NAT policy that gets added: nat (any,any) source static local local destination static remote remote. This command makes no sense to me, and I most of the online research I did regarding NAT had a different syntax. Cisco changed the NAT syntax in 8.3. Prior to, it was the same as PIX.
Again, Juniper just completely dumbs this down and I never had to configure anything like this. I’m not a big fan of any-any policies, so I’m going to do some further research on tightening this down later.
For now, here is the setup and working configs for an SSG5 to ASA5505 VPN with and without sysopt enabled.
Configs:
ASA sysopt
ASA no sysopt
SSG