cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
810
Views
0
Helpful
9
Replies

REMOTE VPN PROBLEM

wasiimcisco
Level 1
Level 1

My remote access vpn client is not able to connnect with internal network.

concentrator is connected with core switch and server 172.28.31.171(server) is also connected in core switch.

InterVLN routing is working fine. server and conncentrator is able to reach other via core switch.

concentrator private Ip address 172.28.31.92/248

VPN POOL: 172.28.31.128/29

Core switch Ip address is 172.28.31.91

Client is able to connect without any problem, but client not able to ping or connect with any network device.

In VPN session i can see bytes send and receive. My LAN-2-LAN tunnles are working fine without any problem.

No firewall involoved in the path between the concentrator and desired server 172.28.31.171.

Both connected on same switch but different VLAN. Inter VLAN routing is working and both are able to ping.

ONly remote access client 172.28.31.128/248 is not able to reach anywhere.

Core switch routing table

ip route 172.28.0.0 255.255.0.0 172.28.31.68

ip route 172.28.0.0 255.255.224.0 172.28.31.77

ip route 172.28.31.128 255.255.255.248 172.28.31.92

ip route 172.28.32.50 255.255.255.255 172.28.31.92

ip route 172.29.0.0 255.255.0.0 172.28.31.68

Concentrator routing table

172.28.0.0 255.255.0.0 via 172.28.31.91

172.29.0.0 255.255.0.0 via 172.28.31.91

192.168.0.0 255.255.0.0 via 172.28.31.91

Split tunnel is enable for

172.28.0.0/0.0.255.255

172.29.0.0/0.0.255.255

172.31.0.0/0.0.255.255

192.168.0.0/0.0.255.255

See the attachement which shows client connects successfully but only sending not receving anything. I have checked

with changing the mtu size and by enabling and disabling the NAT_T. But no success.

1 Accepted Solution

Accepted Solutions

Did you add the IP subnet static route in your core device pointing back to the VPn Concentrator?

View solution in original post

9 Replies 9

andrew.prince
Level 10
Level 10

wasim,

Looking at the screen shot, the problem is with your internal routing, can you actually post the vpn concentrator routing table?

hth.

kindly see the attachement for routing table of concentrator. I dont think so there is routing issue, bcz all network devices are able to reach concentrator, and cocnentrator is able to reach the all network. 172.28.31.91 is switch in which concnetrator private interface is connected. both are able to reach each other, i have so many site to site vpn tunnels and they are working fine, only problem with remote access vpn.

That's fair enough - but the fact that none of your traffic is returning from the core to the vpn client indicates there is a routing issue somewhere.

What is the IP pool range of the remote VPN users??

see the attachement for address pool.

172.28.31.128/29 and see the core switch routing table in which all network is connected.

ip route 172.28.31.128 255.255.255.248 172.28.31.92

it is sending all traffic for destination of 172.28.31.128/29 towards concentrator private interface 172.28.31.92

OK - all that looks, you still could have an issue, you have a route in the core for:-

ip route 172.28.0.0 255.255.224.0 172.28.31.77 - which covers the subnets you are using. I know you have a more specific route to point to the concentrator, rather than the device 172.28.31.92.

I would try testing with another un-used IP subnet...say 172.16.1.0/24 in the concentrator with a route in the core for:-

ip route 172.16.1.0 255.255.224.0 172.28.31.92

And see if the works?

core switch routing

ip route 172.16.1.0 255.255.255.0 172.28.31.92

see the attachement for concentrator configuration for vpn pool, client connects gets the ip but still not able to reach anywhere.

Did you add the IP subnet static route in your core device pointing back to the VPn Concentrator?

problem solved, i changed the vpn pool 172.16.1.0/24 and enable the NAT-T and it is working fine, thanks for your continous support and help and being with me during this troublehsooting.

but i m still thinking about why it works after enabling NAT-T, though there is no firewall involved, no NAT device in the way of concentrator and client.

Please explain, if you know, anyway, once again thanks for your help.

NAT-T is only really used for devices that do not understand the pure IPSEC protocol suite.

NAT-T encapsulates the ESP packets into UDP - which can then traverse the devices that do not understand IPSEC.

Below is a url for the RFC - hope this helps.

http://www.faqs.org/rfcs/rfc3947.html

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: