KB ID 0001104 Dtd 05/09/15
I got sent to Holland this week to look at a firewall deployment, and while I was sat in the Airport, I was going over the job I had to do, when I realised the solution I had suggested had a problem see below;
My brief was to provide remote AnyConnect VPN into the network so the client could get their network setup, and manage things remotely. However as I drew the network out in my head I realised that the situation above was what was going to happen.
How was I going to fix that? Well firstly I thought 'Just put 126.96.36.199 on the management firewall, and move .2 and .3 to the main firewalls'. Well thats fine, but it does not leave me room for expansion, or if the client needs to add remote access to a production network. (Which will be needed in the future).
Then I thought 'Can I put a static route on the main firewalls to route 192.168.100.0/24 to the management firewall'. Which is a pretty horrible solution to be honest, I'm usually on my soap box saying things like 'It's a firewall NOT a router!'. When I have a routing question I don't know the answer to I ring Steve.
He suggested that I'd done something similar for another customer on a project we had worked on. In that case I had NATTED the traffic to the egress interface for management traffic. This was AnyConnect traffic but the principle would be the same, could I translate all the incoming AnyConnect traffic to the inside of the Management firewall? If I could, it would be scalable and simple.
The networking types will be looking at this problem and thinking, 'why not just do all the LAN routing on the switches, and share a routing table between them - job done?' Well at this point I didn't know what the switches were, (and as it turns out there were not the best). And All the LAN routing was being done by something not on the diagram, I did not have access to.
I had an hour and a half to kill before the flight, so I fired up GNS3, and by the time I was called to the gate, I had a complete working AnyConnect Solution, ready to play with the NAT/PAT rules. Twenty minutes into the flight, I had it working, and proved it with WireShark.
In all honesty it's probably taken longer to explain the requirements, than it will do to show you the solution.
Before proceeding make sure you have AnyConnect setup and configured, I've pretty much done ALL the hard work for you in the article below, I will use the same Object Group names in this article, as I did in the following one;
At this point your routing will be breaking the return traffic flow, but here's a top tip, if you enable management on your inside interface, you should be able to ping its IP address from your remote client just to prove connectivity. (This is a standard troubleshooting step I do, as it replies even if the NAT rules are incorrect). To enable, simply do this;
So if you followed my tutorial you will have a NAT rule that looks like this;
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
This basically means DON'T NAT/PAT this traffic, so all IP addresses will be the same on all networks. We need to remove this and tell it to PAT remote AnyConnect VPN traffic to the 'inside' interface, to do that the command we need is;
nat (outside,inside) source dynamic OBJ-ANYCONNECT-SUBNET interface
Lets do that and clear the translations on the firewall.
If you are adamant you want to do this in the ASDM, here is what it looks like in there;
Now give it a test.
Here I have no ACLs applied, if you find you cannot access internal resources, you may not have 'sysopt connection permit-vpn' in your config, (it's a hidden command, so you wont see it). If so, you may need to allow 'inbound' traffic on the outside interface. Execute a packet trace, that will tell you.
Related Articles, References, Credits, or External Links