cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
824
Views
0
Helpful
4
Replies

PIX: Cisco VPN Client connects but no routing

comunicjsc
Level 1
Level 1

Hello,

We have a Cisco PIX 515 with software 7.1(2). It accepts Cisco VPN Client connections without any problem, but no routing is performed towards the internal networks directly connected to the PIX. For instance, my PC is assigned IP address 172.16.2.57 and, then, internal Windows server 172.16.0.12 does not answer ping or RDP attempts. The most irritating thing is that these attempts are registered in Syslog, but always terminated with "SYN timeout", as follows:

2009-01-06 23:23:01 Local4.Info 217.15.42.214 %PIX-6-302013: Built inbound TCP connection 3315917 for outside:172.16.2.57/1283 (172.16.2.57/1283) to inside:ALAI2/3389 (ALAI2/3389)

2009-01-06 23:23:31 Local4.Info 217.15.42.214 %PIX-6-302014: Teardown TCP connection 3315917 for outside:172.16.2.57/1283 to inside:ALAI2/3389 duration 0:00:30 bytes 0 SYN Timeout

2009-01-06 23:23:31 Local4.Debug 217.15.42.214 %PIX-7-609002: Teardown local-host outside:172.16.2.57 duration 0:00:30

We tried to enable and disable "nat-control", "same-security-traffic permit inter-interface" and "same-security-traffic permit intra-interface" but results are the same: the VPN connection completes successfully but remote clients cannot reach the internal servers.

I'm attaching the relevant configurations to fully understand the problem:

interface Ethernet0

speed 100

duplex full

nameif outside

security-level 0

ip address xx.yy.zz.tt 255.255.255.240

!

interface Ethernet1

nameif inside

security-level 100

ip address 172.16.0.1 255.255.255.0

!

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 172.16.2.56 255.255.255.248

!

access-list outside_cryptomap_dyn_20 extended permit ip 172.16.0.0 255.255.255.0 172.16.2.56 255.255.255.248

!

access-list VPN_client_group_splitTunnelAcl standard permit 172.16.0.0 255.255.255.0

!

ip local pool pool_vpn_clientes 172.16.2.57-172.16.2.62 mask 255.255.255.248

!

nat-control

global (outside) 12 xx.yy.zz.tt

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 12 172.16.0.12 255.255.255.255

!

group-policy VPN_clientes internal

group-policy VPN_clientes attributes

default-domain value xxyyzz.net

group-policy VPN_client_group internal

group-policy VPN_client_group attributes

split-tunnel-policy tunnelspecified

split-tunnel-network-list value VPN_client_group_splitTunnelAcl

default-domain value xxyyzz.local

!

I'm not attaching any cryptographic algorithms details because the VPN is completed successfully, as I said at the beginning. Besides, routing tables are not relevant in my opinion, because the unreachable hosts are directly connected to the internal LAN of the PIX 515.

Thank you very much.

1 Accepted Solution

Accepted Solutions

JORGE RODRIGUEZ
Level 10
Level 10

can you confirm asa have NAT traversal enable, if not, enable it in asa and have vpn clients try again.

PIX/ASA 7.1 and earlier

pix(config)#isakmp nat-traversal 20

PIX/ASA 7.2(1) and later

pix(config)#crypto isakmp nat-traversal 20

Jorge Rodriguez

View solution in original post

4 Replies 4

JORGE RODRIGUEZ
Level 10
Level 10

can you confirm asa have NAT traversal enable, if not, enable it in asa and have vpn clients try again.

PIX/ASA 7.1 and earlier

pix(config)#isakmp nat-traversal 20

PIX/ASA 7.2(1) and later

pix(config)#crypto isakmp nat-traversal 20

Jorge Rodriguez

Great, Jorge!

nat-traversal was enough to solve the problem. Routing to internal servers is working now for remote VPN clients.

Thank you very much!

Comu, glad it was resolved and pleasure to hepl.. thanks for rating.

Regards

Jorge

Jorge Rodriguez

test

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: