cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3441
Views
0
Helpful
17
Replies

problem access LAN with remote vpn client 5.x on Router 800

hdoramane
Level 1
Level 1

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

 

 

 

 

 

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

17 Replies 17

ghostinthenet
Level 7
Level 7

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.

 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

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?

 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

 

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

 

 Its looks NAT is Ok 

the remove of ACL 100 is done but still no ping to servers 192.168.10.2/4

 thx

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.

 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

 

 

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 ---               ---

 

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.

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

 

No change when you enabled the proxy ARP?

 

 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#

 

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.