Routing between two heterogenous S2S VPNs

[isa]

Hi,

We currently have a situation where we have a S2S VPN between an ASA 5505 at Site A and an ASA 5510 at Site B, and then we have a second S2S VPN between a Symantec SGS 5420 at Site A and a Symantec SGS 1600 at Site C.

So Site A is the "hub" of these two S2S VPNs, running over different gateways.

The Symantec SGS 5420 is the default route for Site A, but static routes have been added to all the devices at Site A to direct traffic to Site B to the ASA 5505, and that worked like a charm.

Both of these VPNs work well to/from Site A. Site A devices can ping devices at either remote site, and either remote site can ping devices at Site A.

What we need to accomplish next is to allow devices at Site B and devices at Site C to communicate with each other, and I have to admit that I'm at a loss there. Is it just a matter of setting up the appropriate static routes on all of the devices, or is there more to it? Also, if I were to ditch the Symantec SGS devices completely and get everything going with the single ASA 5505 at Site A as the "hub device", would that make this easier?

[Jouni Forss]

Hi,

So what you essentially have its a Main Site with 2 Remote Sites. Furthermore the Main Site holds a different VPN Gateway for each Remote Site.

Now you want to enable traffic to flow between the 2 Remote Sites. This should be no problem.

What you would have to make sure are atleast the following

• Both Main Site VPN gateways need to have a route for the other VPN gateways Remote Site network
• Main Site ASA needs a L2L VPN addition that specifies Site C as local network and Site B as remote network
• Main Site SGS needs a L2L VPN addition that specifies Site B as local network and Site C as remote network
• Remote Site B needs a L2L VPN addition that specifies Site B as the local network and Site C as the remote network
• Remote Site C needs a L2L VPN addition that specifies Site C as the local network and Site B as the remote network
• All the devices need the appropriate NAT0 configurations to match this traffic

The above things should be the key points. You just need to define the interesting traffic on all the VPN gateways involved so the traffic gets forwarded from end to end.

Naturally if you had only a single VPN gateway on the Main Site then there would be fewer devices to configure. I wonder if you currently also have 2 ISP links on the Main Site for both of the VPN gateways or do they use the same single ISP connection?

Hope this helps

- Jouni

[isa]

Thanks! I think that's got me started, but if you bear with me, I'm going to review some things and see what I'm missing, as it's still not quite working.

On Site A, I've modified the "local network" on the SGS5420 to be a network group entity comprised of both Site A and Site B, with the "remote network" still just Site C.

On Site A, I've modified the "local network" on the ASA5505 to be a network group entity comprised of both Site A and Site C, with the "remote network" still just Site B.

On Site C, I've modified the "remote network" on the SGS1600 to be a network group entity comprised of both Site A and Site B, with the "local network" still just site C.

On Site B, I've modified the "remote network" on the ASA5510 to be a network entity comprised of both Site A and Site C, with the "local network" still just site B.

At Site A, the SGS5420 has a static route pointing all traffic for Site B to the local (Site A) network interface of the ASA5505.

At Site A, the ASA5505 has a static route pointing all traffic for Site C to the local (Site A) network interface of the SGS5420.

I believe this is all as youv'e described above. The only part I'm shaky on is the last line, with "All the devices need the appropriate NAT0 configurations to match this traffic". When setting up the ASA5505<-->ASA5510 S2S VPN, I used the simple wizard and selected to exempt traffic from NAT. I assume my counterpart at Site B (that's the only site of these I don't personally control) did the same, since traffic between our sites is passing fine. When setting up the SGS5420<-->SGS1600 S2S VPN, I used a set of address transform rules which state "Use Original Source Address" for all cases, which I believe accomplishes the same thing.

I'm still unable to ping hosts at Site B from Site C, though. Any thoughts?

As to your question, both devices at Site A are using a single ISP connection. This seemingly complicated setup was chosen because I have a very short time frame to get this up and running, and replacing the SGS pair, given provisioning time, and especially given that they're the primary firewalls (with a lot of configuration and rules) at Sites A and C (which are geographically remote from each other) just seemed like it was not going to happen in time.

Thanks a million times for looking at this, by the way. I'm not an expert in this, so getting a skilled set of eyes on it is phenomenal.

[Jouni Forss]

Hi,

Well if we presume for example that Site A and Site B ASA firewalls have a configuration something like this (on the CLI)

nat (inside) 0 access-list

Then it wold meant that the ACL named in the command would contain the networks between which no NAT should be performed. So you should probably find Site A and Site B networks on those.

On Site A ASA you would need to add another line to the ACL and define the source network as Site C and destination network as Site B

On the Site B ASA you would need to add another line to the ACL and define the source network as Site B and destination network as Site C

Sadly, I have no expirience of the other device models you are using so I can't really help with those. Though I imagine you should be able to check the NAT0 configurations used for the VPN on those devices to achieve the same.

- Jouni

[isa]

Thanks again.

I've configured the SGSes with what I believe to be the equivalent NAT rules to what you're suggesting above. They basically come down to "any traffic of any kind coming in or going out over a VPN is exempt from NAT". (Since we don't have any other VPN traffic on those devices, it was simple to just use the blanket rule.) On the ASA5505 at Site A, the configuration lines for NAT relevant to this tunnel read:

nat (inside,outside) source static DEISubnets DEISubnets destination static MontrealSubnet MontrealSubnet no-proxy-arp route-lookup

"DEISubnets" is the group entity comprising Site A and C, and "MontrealSubnet" is Site B.

I didn't set that line myself -- that's what was set when I used the S2S VPN Wizard and selected the checkbox to exempt it from NAT. (I don't have the config for the ASA5510 at Site B handy, as that's managed by someone else, but I could get it or request changes to it if needed.)

There seem to be some other issues with the configuration they want me to implement anyway, and I it seems to be inefficient to use Site A as a hub between Sites B and C, so I think that rather than keep chipping away at this, I'm going to propose that we replace the SGS1600 at Site C with an ASA5505, and: a) move all the S2S VPNs over to the ASAs; b) establish essentially a triangle of S2S VPNs between the three sites so that we each communicate with each other directly rather than shunting through one hub site; c) we start transitioning entirely off the SGSes for everything. The SGSes are long EOL-ed anyway, and the only tricky bit about replacing them was the S2S VPN between Sites A and C. Not technically solving the problem posed here, but a solution for what we want to do, and probably a better one in the long run, I think.

[Jouni Forss]

Hi,

Sounds like a good plan. It will certainly make the traffic flow a bit better when the sites communicate directly instead of consuming the Main Site bandwith also.

Also when every device is of same brand it will make for easier configurations/troubleshooting. Naturally different software levels (8.2 or below vs. 8.3 or above) might cause differences in the configuration format.

If the ASAs would be in place it would be naturally probably easy to solve any traffic flow problem. At the moment the other brand devices are a total mystery to me

Shame I can't help more.

Naturally the Site A to Site B should be easy to confirm with configurations and using some diagnostic commands on the ASA units. But then again the Site A to Site C is not something I know how to troubleshoot since I dont know the devices at all.

Your best bet is probably to start looking at the VPN packet counters (and networks) on ASA monitor page to confirm that the connection for the 2 Remote networks has even formed through test and track where the forwarding of packets stops.

If you happen to decide to change to ASAs and face problems with the L2L VPN connections I could always take a look.

- Jouni