gustaavMemberSeptember 25, 2015 at 7:59 am #165801
[SIZE=14px]Hello. We have this VPN scenario with our Cisco ASA firewalls:[/SIZE]
- Our main’s office LAN subnet: 172.16.0.0/25
- Our branch’s office LAN subnet: 172.16.1.0/25
- Our branch’s office IP pool for remote VPN: 172.16.1.128/25
[SIZE=14px]There’s a site-to-site VPN configured between the Cisco ASA firewall of the main office and the Cisco ASA firewall of the branch office. The branch office has several VPN remote users. So:[/SIZE]
- Traffic between subnets 172.16.0.0/25 and 172.16.1.0/25 works fine.
- Traffic between subnets 172.16.1.0/25 and 172.16.1.128/25 works fine through Cisco VPN client.
[SIZE=14px]The question is: What ACL/NAT configuration do I need in the branch’s firewall in order to allow traffic between 172.16.1.128/25 subnet and 172.16.0.0/25 subnet?[/SIZE]
[SIZE=14px]Thanks in advance![/SIZE]
AnonymousSeptember 27, 2015 at 11:21 am #371856
Your issue isn’t with an ACL as a separate entry, your issue with with the site-to-site IPSec tunnel. Such a tunnel is built by a Phase 1 and then a Phase 2 ‘Security Association’. Put simply, the Phase 1 is when the 2 ASA devices agree to talk securely to each other, and the Phase 2 is when they agree what traffic will pass between them. The Phase 2 settings describe the subnets or address ranges that are allow to talk thru the tunnel. You’ll need to change the Branch Office ASA Phase 2 settings to include the second subnet, or change the single existing subnet from 172.16.1.0/25 to 172.16.1.0/24 (may be simpler).
yehudahMemberSeptember 28, 2015 at 10:23 am #391179
Thanks for your response Rickles. I’m trying now your second solution. I changed the remote network subnet to a pool on the same subtnet of the branch office. But again, the same happens. Despite is the same subnet now, the remote network does not connects to the main office subnet. Am I missing something here?
AnonymousSeptember 28, 2015 at 1:34 pm #371857
Sorry, but I didn’t understand your reply. Your Main office has one subnet defined, so that entire subnet should appear in the Main Office ASA Phase 2 settings. Your Branch office has 2 subnets, which are actually 2 halves of 1 std ‘class c’ subnet. So in the Branch Office ASA Phase 2 settings, you should either have both individual subnets listed, or just the one larger subnet. If you changed the Branch office ASA Phase 2 to just the larger, single subnet value and nothing changed (what worked before still works but what didn’t work before still doesn’t), then remove the change you just made, and add the second subnet in as a new, separate entry.
It’s been a while since I’ve been into an ASA so had a quick look on-line. It looks like you’ll have to add your second Branch subnet as ‘local’ to the Branch ASA, and add that same subnet as ‘Remote’ on the Main Office ASA.
yehudahMemberSeptember 29, 2015 at 7:59 am #391180
Sorry, but, I’m new at this, so, how exactly do I set the branch subnet as ‘local’ in the branch ASA, and how do I set the branch subnet as ‘remote’ on the main ASA?
scowlesMemberSeptember 30, 2015 at 4:24 am #331770
Without seeing the actual config of both ASA’s, it hard to isolate where the problem is happening.
But I can think of a few things to check…
Check the ACL for the remote access vpn (usually the split tunnel ACL listed in group-policy) on the branch ASA and make sure it includes the main office netblock. You can verify this in the VPN client after the tunnel is established. This ACL defines what traffic gets encrypted from the client PC. If its 0.0.0.0, then the remote access tunnel is configured to tunnel everything. If that’s the case, move to the next step.
Check the ACL configuration for the L2L tunnel between Branch office and Main office. This will be the ACL referenced in the crypto-map statement (show run crypto) for the L2L tunnel. Make sure the ACL includes remote access netblock (172.16.1.128/25 as source) and main office netblock (172.16.0.0/25 as destination). Same thing for the Main Office ASA, but the ACL source and destination will be reversed. i.e. reply traffic. The command “show crypto ipsec sa” will show you which security associations (SA’s) were formed for the L2L tunnel. Each ASA should have an entry for this traffic. This command will also help in determining which traffic is being encrypted/decrypted. There should be an SA entry for 172.16.1.128/25 to 172.16.0.0/25. Then check no nat below.
Check the ACL that is used in the NO-NAT statements. Make sure there is a NO NAT statement referencing outside to outside traffic “nat (outside,outside) …”. This is usually where the problem is when a remote access tunnel cannot access another office via L2L VPN. Without the NO NAT being configured correctly, remote access vpn traffic for the main office would be nat’d instead of being routed through the L2L tunnel. Remember, remote access vpn traffic arrives on the outside interface, gets decrypted, route lookup and should leave on the outside interface (via L2L tunnel). This is why the NO NAT statement needs to reference outside to outside traffic for remote access VPN’s that need to access another netblock via L2L tunnel.
Check route table on branch ASA and make sure it has a route to main office internal netblocks via outside interface. Especially if you have summary routes for all of RFC1918 address space (private) that points to inside interface. In your case, add “route outside 172.16.0.0/25 x.x.x.x. The x.x.x.x is the ASAs default route. You will need to check the main office ASA for the same thing, just reversed.
At a 30,000 foot view…. think of the traffic flow through both ASAs when a remote access client (connected to the branch ASA) attempts to access the main office via the L2L VPN.
1) Remote access VPN client wants to send a packet of data with a source of 172.16.1.128/25 and a destination of 172.16.0.0/25.
2) Client PC does a route lookup and determines it needs to route this packet through the remote access tunnel interface.
3) Packet gets encrypted and then routed through the remote access tunnel interface
4) Packet arrives at branch office ASA on the outside interface and is decrypted
5) Branch office ASA does a route lookup to determine how to route the decrypted packet
6) If everything is configured correctly, the branch office ASA will determine it needs to route this packet back out the outside interface via the L2L tunnel. The NO NAT configuration is important here.
7) Packet will be encrypted and sent through the L2L tunnel between branch office and main office
8) Packet arrives at main office ASA on the outside interface and is decrypted
9) Main office ASA does a route lookup to determine how to route the decrypted packet
10) If everything is configured correctly, the main office ASA will determine it needs to route this packet to the inside interface of the main office ASA to reach its final destination (172.16.0.0/25)
11) Main office ASA then sends this packet out the inside interface to its final destination
12) Packet of data arrives at final destination (like a server at main office)
The reply traffic follows the same steps, just reverse source and destination.
You must be logged in to reply to this topic.