cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
637
Views
0
Helpful
2
Replies

VPN NAT rule issue

GrahamB_SEMC
Level 1
Level 1

Hello folks, I've had a lot of trouble trying to resolve this issue, but hoping someone here can enlighten me.

I have a remote site that hosts a number of services that we manage remotely with an IPSec VPN connection. When connecting to the site we establish connection fine and can do most actions like RDP and connect to servers for maintenance but one service fails to connect unless I add a NAT exempt rule to the router configuration (ASA 5505).

Once this rule is in place the service works, but other services that originally worked stop working. In short, this rule must be in place while doing one task, but then taken out for other tasks. I'm hoping there is some sort of rule or behavior I can add to the ASDM configuration making it so I no longer have to manually add this rule each time I connect.

Here's the rule details:

      access-list outside_nat0_outbound line 1 extended permit ip 192.168.15.192 255.255.255.192 192.168.15.0 255.255.255.0

      nat (outside) 0 access-list outside_nat0_outbound outside tcp 0 0 udp 0

When establishing the connection without the rule in place the ASDM syslog shows these warnings:

      Deny tcp src inside:<inside_host_ip>/61745 dst outside:10.100.32.203/135 by access-group "inside_access_in" [0x0, 0x0]

The weird thing is 10.100.32.203 is my host computer's internal IP. Its not even the external IP of the network I'm connecting from.

Is it possible the problem stems from the VPN pool using a subset of the inside VLAN's subnet? The inside VLAN is 192.168.15.0/24 and the VPN is 192.168.15.200-250. I'm willing to reconfigure the VPN address pool but need to do it remotely and am not aware how to make this reconfiguration safely without losing my remote access since gaining physical access to the router itself is very difficult currently.

If more details are needed I'm happy to provide them.

1 Accepted Solution

Accepted Solutions

rizwanr74
Level 7
Level 7

Hi GrahamB,

Yes, it is the problem with over-lapping subnet.

There is plenty of private-address available, so please create a new group-policy and tunnel-group and complete

separate pool of ip address altogather and remote in with it, when new pool fix your issue, can safely delete the old one.

Hope this helps.

thanks

Rizwan Rafeek.

View solution in original post

2 Replies 2

rizwanr74
Level 7
Level 7

Hi GrahamB,

Yes, it is the problem with over-lapping subnet.

There is plenty of private-address available, so please create a new group-policy and tunnel-group and complete

separate pool of ip address altogather and remote in with it, when new pool fix your issue, can safely delete the old one.

Hope this helps.

thanks

Rizwan Rafeek.

Thanks for the reply Rizwan.

I made the changes by adding a new Group and VPN user to get a 192.168.16.x IP address and configured the access rules to allow connection. I am able to successfully connect to one of the services but will confirm the other services work after coordinating with a coworker.  I'll follow up tomorrow if everything worked.