10-03-2014 07:05 AM
Hi,
I have a strange problem with remote vpn client, I can connect with client vpn but access to LAN servers
It's seems like a problem with NAT Rules because the vpn traffic must not be translated, I did all changes but still not work
Otherwise, what's about the order of NAT-Rules?
If you can see with attached configs, thanks for any idea
Solved! Go to Solution.
10-06-2014 07:14 AM
Obviously I shouldn't answer questions before coffee. I was mixing up the "acl" statement with the "access-restrict" statement. We'll definitely need to put that back. Before you do, let's delete ACL 100 and redefine it as "access-list 100 permit ip 192.168.10.0 0.0.0.255 any" with no other lines... just to simplify.
The fact that you're able to ping 192.168.10.1 from the VPN tells me that we're doing alright there. Return traffic from LAN hosts should follow the default gateway path and reach the VPN clients, but that's not happening. Let's turn on the proxy arp on the VLAN 10 interface and see if that makes a difference. It shouldn't matter if 192.168.10.1 is the default gateway, but the fact that the virtual template is anchoring on VLAN 10 makes me think this might be a factor.
10-03-2014 02:30 PM
It's definitely a NAT issue.
You're using a 10.x.x.x network for your VPN client pool and your NAT ACLs translate all traffic coming from the 192.168.x.x network on the inside to the IPv4 address of the FastEthernet4 interface. This means that return traffic to your VPN clients will come from the translated address rather than the actual address and will not cross the VPN back to you.
Given that all of your NAT rules reference an overload on the same WAN interface, I would simplify it and bring it down to one rule so that you can control the order of operations.
Instead of this:
ip nat inside source list 1 interface FastEthernet4 overload ip nat inside source list 2 interface FastEthernet4 overload ip nat inside source list 111 interface FastEthernet4 overload ! access-list 1 remark INSIDE_IF=Vlan1 access-list 1 remark CCP_ACL Category=2 access-list 1 permit 172.17.225.232 0.0.0.7 access-list 2 remark INSIDE_IF=Vlan10 access-list 2 remark CCP_ACL Category=2 access-list 2 permit 192.168.10.0 0.0.0.255 access-list 111 remark CCP_ACL Category=18 access-list 111 deny ip host 192.168.10.1 host 10.10.10.1 access-list 111 deny ip host 192.168.10.1 host 10.10.10.2 access-list 111 deny ip host 192.168.10.1 host 10.10.10.3 access-list 111 deny ip host 192.168.10.1 host 10.10.10.4 access-list 111 deny ip host 192.168.10.1 host 10.10.10.5 access-list 111 deny ip host 192.168.10.1 host 10.10.10.6 access-list 111 deny ip host 192.168.10.1 host 10.10.10.7 access-list 111 deny ip host 192.168.10.1 host 10.10.10.8 access-list 111 deny ip host 192.168.10.1 host 10.10.10.9 access-list 111 deny ip host 192.168.10.1 host 10.10.10.10 access-list 111 permit ip 192.168.10.0 0.0.0.255 any
Try something like this:
ip nat inside source list ACL_NAT_WAN interface FastEthernet4 overload ! object-group network OG_RFC1918 10.0.0.0 /8 172.16.0.0 /12 192.168.0.0 /16 ! ip access-list extended ACL_NAT_WAN deny ip object-group OG_RFC1918 object-group OG_RFC1918 permit ip object-group OG_RFC1918 any
In most cases, you're going to want to ensure that NAT doesn't happen between private IPv4 addresses and public ones while at the same time making sure that NAT does happen between private IPv4 addresses and public ones. The above configuration simplifies this and won't require you to go back and edit the NAT configuration every time you make a change.
10-06-2014 01:40 AM
Thanks for your reply
I tested the suggested modification and it's still not work
I change all NAT Rules and Access-Lists but when I connect on remote vpn client, I can't ping my servers with 192.168.10.2 and 192.168.10.4
Please advice if there's another idea
my update config on attached
thx
10-06-2014 05:44 AM
I suspect we're looking beyond NAT at this point. Just to be sure, let's make the following change:
interface Virtual-Template1 type tunnel ip nat inside
When you connect on your VPN and attempt to reach the servers, check the router with a "show ip nat translation" and see if there are any entries for the 10.10.10.x addresses. If there aren't (and there shouldn't be) then we're dealing with another problem.
Two more questions: Are you able to ping the router's LAN IPv4 address across the VPN? Are the servers using 192.168.10.1 as their default gateway?
10-06-2014 06:05 AM
Thanks for reply
I did change on interface " interface Virtual-Template1 type tunnel " and put it on ip nat inside but no changes...
sh ip nat translations:
gw-fr-tf-4419#sh ip na translations
Pro Inside global Inside local Outside local Outside global
tcp 78.X.x.x:4001 172.17.225.234:4001 --- ---
tcp 78.x.x.x:4005 172.17.225.234:4005 --- ---
udp x.x.x.x:4500 172.17.225.234:4500 194.180.56.8:4500 194.180.56.8:4500
udp x.x.x.x:4500 172.17.225.234:4500 194.180.56.244:4500 194.180.56.244:4500
udp x.x.x.x:4500 172.17.225.234:4500 194.180.57.244:4500 194.180.57.244:4500
tcp x.x.x.x:5001 172.17.225.234:5001 --- ---
Two more questions: Are you able to ping the router's LAN IPv4 address across the VPN?
Yes I can ping the routers LAN IPv4 address accross the VPN
Are the servers using 192.168.10.1 as their default gateway?
Yes it's
Thx
10-06-2014 06:14 AM
The change to the tunnel was more for consistency than anything else. The exceptions established for NAT would have bypassed any problems there.
The "show ip nat translation" tells us that we definitely don't have a NAT problem at this point. More likely an ACL issue.
Can you remove ACL 100 from the client configuration and give it another test?
crypto isakmp client configuration group guerin no acl 100
10-06-2014 06:23 AM
Its looks NAT is Ok
the remove of ACL 100 is done but still no ping to servers 192.168.10.2/4
thx
10-06-2014 06:32 AM
At this point, I'm not seeing anything in the configuration that would prevent this from working. Are you able to ping these IPv4 addresses from the router's command-line interface?
If so, let's see what results you get when you connect a VPN client and try to ping it from the server. For best debugging results, you'll need to make these changes:
interface Vlan10 ip redirects ip unreachables ip proxy-arp
Let me know what results you get from a ping from the server to the client.
10-06-2014 07:02 AM
Hi
I can ping all address from router:
gw-fr-tf-4419#PING 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
gw-fr-tf-4419#PING 192.168.10.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
gw-fr-tf-4419#
Unfortunately I have a remote access to router, so I can't test the ping from server to client.
Let's me know we need ipsec acl like ACL 100 or ACL104?
Thx
10-06-2014 07:08 AM
after connecting on VPN, I can see :
gw-fr-tf-4419#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 78.X.X.X:54771 10.10.10.2:54771 173.194.40.117:443 173.194.40.117:443
tcp 78.X.X.X:2492 10.10.10.3:2492 134.170.3.184:2492 134.170.3.184:2492
tcp 78.X.X.X:55830 10.10.10.3:55830 4.26.66.40:80 4.26.66.40:80
tcp 78.X.X.X:55831 10.10.10.3:55831 173.194.67.102:443 173.194.67.102:443
tcp 78.X.X.X:55832 10.10.10.3:55832 173.194.67.102:443 173.194.67.102:443
tcp 78.X.X.X:1024 10.10.10.4:2492 134.170.3.184:2492 134.170.3.184:2492
tcp 78.X.X.X:56368 10.10.10.4:56368 208.89.14.135:80 208.89.14.135:80
tcp 78.X.X.X:56369 10.10.10.4:56369 208.89.14.135:80 208.89.14.135:80
tcp 78.X.X.X:56372 10.10.10.4:56372 132.245.194.242:443 132.245.194.242:443
tcp 78.X.X.X:1025 10.10.10.5:2492 134.170.3.184:2492 134.170.3.184:2492
udp 78.X.X.X:49779 10.10.10.5:49779 212.27.54.252:53 212.27.54.252:53
udp 78.X.X.X:50648 10.10.10.5:50648 212.27.54.252:53 212.27.54.252:53
udp 78.X.X.X:54176 10.10.10.5:54176 212.27.54.252:53 212.27.54.252:53
udp 78.X.X.X:55928 10.10.10.5:55928 212.27.54.252:53 212.27.54.252:53
tcp 78.X.X.X:56390 10.10.10.5:56390 208.89.14.135:80 208.89.14.135:80
tcp 78.X.X.X:56399 10.10.10.5:56399 157.56.250.66:443 157.56.250.66:443
tcp 78.X.X.X:56400 10.10.10.5:56400 157.56.250.66:443 157.56.250.66:443
tcp 78.X.X.X:56403 10.10.10.5:56403 157.56.250.66:443 157.56.250.66:443
tcp 78.X.X.X:56405 10.10.10.5:56405 157.56.250.66:443 157.56.250.66:443
tcp 78.X.X.X:56408 10.10.10.5:56408 4.26.66.40:443 4.26.66.40:443
Pro Inside global Inside local Outside local Outside global
tcp 78.X.X.X:56409 10.10.10.5:56409 208.89.14.135:80 208.89.14.135:80
tcp 78.X.X.X:56410 10.10.10.5:56410 208.89.14.135:80 208.89.14.135:80
tcp 78.X.X.X:56411 10.10.10.5:56411 4.26.66.40:443 4.26.66.40:443
tcp 78.X.X.X:56412 10.10.10.5:56412 4.26.66.40:443 4.26.66.40:443
tcp 78.X.X.X:56413 10.10.10.5:56413 4.26.66.40:80 4.26.66.40:80
tcp 78.X.X.X:56414 10.10.10.5:56414 4.26.66.40:80 4.26.66.40:80
tcp 78.X.X.X:56415 10.10.10.5:56415 4.26.66.40:80 4.26.66.40:80
tcp 78.X.X.X:56416 10.10.10.5:56416 4.26.66.40:80 4.26.66.40:80
tcp 78.X.X.X:56418 10.10.10.5:56418 4.26.66.40:80 4.26.66.40:80
udp 78.X.X.X:58641 10.10.10.5:58641 212.27.54.252:53 212.27.54.252:53
udp 78.X.X.X:61756 10.10.10.5:61756 212.27.54.252:53 212.27.54.252:53
tcp 78.X.X.X:4001 172.17.225.234:4001 --- ---
tcp 78.X.X.X:4005 172.17.225.234:4005 --- ---
udp 78.X.X.X:4500 172.17.225.234:4500 194.180.56.8:4500 194.180.56.8:4500
udp 78.X.X.X:4500 172.17.225.234:4500 194.180.56.244:4500 194.180.56.244:4500
udp 78.X.X.X:4500 172.17.225.234:4500 194.180.57.244:4500 194.180.57.244:4500
tcp 78.X.X.X:5001 172.17.225.234:5001 --- ---
10-06-2014 07:16 AM
That makes sense. After removing "acl 100" from the VPN definition, all client traffic started redirecting over the VPN, which would create NAT entries as the client tries to get out to the Internet. Once we put ACL 100 back into the VPN definition, those should go away.
10-06-2014 07:48 AM
I add ACL 100 and mapped to group vpn
still no ping to 192.168.10.2/4
it's looks like:
!
ip nat inside source static tcp 172.17.225.234 4001 interface FastEthernet4 4001
ip nat inside source static tcp 172.17.225.234 5001 interface FastEthernet4 5001
ip nat inside source static tcp 172.17.225.234 4005 interface FastEthernet4 4005
ip nat inside source list ACL_NAT_WAN interface FastEthernet4 overload
ip route 0.0.0.0 0.0.0.0 78.X.X.X
ip route 192.168.10.0 255.255.255.0 78.X.X.X
!
ip access-list extended ACL_NAT_WAN
deny ip object-group OG_RFC1918 object-group OG_RFC1918
permit ip object-group OG_RFC1918 any
!
logging trap debugging
access-list 100 permit ip 192.168.10.0 0.0.0.255 any
dialer-list 1 protocol ip permit
dialer-list 2 protocol ip permit
thx
10-06-2014 07:49 AM
No change when you enabled the proxy ARP?
10-06-2014 07:59 AM
gw-fr-tf-4419(config)#int vlan 10
gw-fr-tf-4419(config-if)#IP PRO
gw-fr-tf-4419(config-if)#IP PROxy-arp
No ping and I can ping the servers from routers /
gw-fr-tf-4419#ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
gw-fr-tf-4419#ping 192.168.10.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms
gw-fr-tf-4419#
10-06-2014 08:20 AM
We've covered the NAT and we're sure the VPN itself is working or you wouldn't be able to ping the router. Are you able to reach any other hosts on the 192.168.10.0/24 subnet? I'm wondering if there's something missing on that end of things.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide