remote access vpn connectivity to site 2 site tunnel network

WILLIAM STEGMAN · ‎10-24-2006

I have remote access vpn setup on a pix 515 running 7.2. I also have a site 2 site tunnel from that same pix to an ASA 5510. When VPN users connect to the remote access vpn, they are able to reach resources on the PIXs inside interface. The site 2 site tunnel is also operational and working fine. The problem occurs when remote access users try to access the other end of the site 2 site tunnel.

remote access vpn subnet - 192.168.8.0/24

local lan behind PIX inside interface - 10.4.0.0/16

remote lan on other side of tunnel, behind ASA - 10.4.1.0/24

My nonat access-list on the PIX is below. My understanding is I need to exempt the source network destination network traffic from NAT. Example, source being the remote access vpn users (192.168.8.0/24) going to ASA end of tunnel (10.4.1.0/24)

access-list nonat line 1 extended permit ip 192.168.64.0 255.255.255.0 10.4.0.0 255.255.0.0

access-list nonat line 2 extended permit ip 192.168.64.0 255.255.255.0 192.168.8.0 255.255.255.0

access-list nonat line 3 extended permit ip 10.0.0.0 255.0.0.0 192.168.8.0 255.255.255.0

access-list nonat line 4 extended permit ip 192.168.8.0 255.255.255.0 10.0.0.0 255.0.0.0

access-list nonat line 5 extended permit ip 192.168.8.0 255.255.255.0 192.168.64.0 255.255.255.0

access-list nonat line 6 extended permit ip 192.168.8.0 255.255.255.0 10.4.1.0 255.255.255.0

access-list nonat line 7 extended permit ip 10.0.0.0 255.0.0.0 192.168.64.0 255.255.255.0

access-list nonat line 8 extended permit ip 10.0.0.0 255.0.0.0 10.4.1.0 255.255.255.0

access-list nonat line 9 extended permit ip 10.4.1.0 255.255.255.0 10.0.0.0 255.0.0.0

access-list nonat line 10 extended permit ip 10.4.0.0 255.255.255.0 192.168.63.0 255.255.255.0

From the ASA end, the opposite access-list

access-list inside_nat0_outbound_V1; 4 elements

access-list inside_nat0_outbound_V1 line 1 extended permit ip 10.4.1.0 255.255.2

55.0 10.0.0.0 255.0.0.0 (hitcnt=0)

access-list inside_nat0_outbound_V1 line 2 extended permit ip 192.168.63.0 255.2

55.255.0 10.4.0.0 255.255.255.0 (hitcnt=0)

access-list inside_nat0_outbound_V1 line 3 extended permit ip any 192.168.62.0 2

55.255.255.0 (hitcnt=0)

access-list inside_nat0_outbound_V1 line 4 extended permit ip 10.4.1.0 255.255.2

routing on my PIX

S 192.168.8.0 255.255.255.0 [1/0] via 10.1.10.10, outside

10.1.10.10 is the address of the comcast cable modem

routing on the ASA

S 192.168.8.0 255.255.255.0 [1/0] via 10.1.10.1, outside

thank you,

Bill

attrgautam · ‎10-24-2006

just to get it clarified, by default, PIX doesnt allow the traffic that comes in through an interface to go back through the same interface. However, that behaviour can be overridden with the following command

same-security-traffic permit intra-interface.

is this applied ? else can you apply this and see if it solves your issue ?

martin_lx1980 · ‎10-25-2006

hello,

Do you know whether the feature can work well on pix 6.x and Router IOS

attrgautam · ‎10-25-2006

pix 6.x no it is supported from min 7.x , no such restriction in IOS u can do this routers without any hassles.

martin_lx1980 · ‎10-26-2006

hi,attrgautam

I do the experiment with two IOS routers.

R1:

crypto isakmp policy 10

hash md5

authentication pre-share

group 2

crypto isakmp key cisco address y.y.y.y

crypto isakmp client configuration group vpnclient

key cisco

pool vpnpool

acl 101

crypto ipsec transform-set vpnset esp-des esp-md5-hmac

crypto dynamic-map dynmap 10

set transform-set vpnset

crypto map vpnmap isakmp authorization list vpnclient

crypto map vpnmap client configuration address respond

crypto map vpnmap 5 ipsec-isakmp dynamic dynmap

crypto map vpnmap 10 ipsec-isakmp

set peer y.y.y.y

set transform-set vpnset

match address 101

interface FastEthernet0/0

ip address x.x.x.x 255.255.255.248

ip nat outside

crypto map vpnmap

interface FastEthernet0/1

ip address 192.168.1.1 255.255.255.0

ip nat inside

ip local pool vpnpool 192.168.3.1 192.168.3.254

ip classless

ip route 0.0.0.0 0.0.0.0

ip nat inside source list 102 interface FastEthernet0/0 overload

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

access-list 101 permit ip 192.168.3.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 102 deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 102 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

access-list 102 deny ip 192.168.3.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 102 permit ip 192.168.1.0 0.0.0.255 any

R2:

crypto isakmp policy 10

hash md5

authentication pre-share

group 2

crypto isakmp key cisco address x.x.x.x

crypto ipsec transform-set vpnset esp-des esp-md5-hmac

crypto map vpnmap 10 ipsec-isakmp

set peer x.x.x.x

set transform-set vpnset

match address 101

interface FastEthernet0/0

ip address y.y.y.y 255.255.255.248

ip nat outside

crypto map vpnmap

interface FastEthernet0/1

ip address 192.168.2.1 255.255.255.0

ip nat inside

ip route 0.0.0.0 0.0.0.0

ip nat inside source list 102 interface FastEthernet0/0 overload

access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

access-list 102 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 102 deny ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

access-list 102 permit ip 192.168.2.0 0.0.0.255 any

Ipsec tunnel can setup between R1 and R2.But when i dialin R1 with vpnclient ,ping test from vpnclient to 192.168.2.2(R2 inside pc)failed.Does really no such restriction in IOS exist or i make incorrect config?

attrgautam · ‎11-03-2006

Ok didnt look at this post for some time. First suggestion would be use different ACLs for the Dialin VPN and LAN-to-LAN between R1 and R2.

I am assuming there is some ACL mismatch happening. Can you try that and let me know if there is any improvement ?

sh crypto ipsec sa output would be useful when you are pinging.

martin_lx1980 · ‎11-06-2006

attrgautam:

Thank you for your suggestion.I remove split-tunnel acl from vpnclient and I am able to ping 192.168.2.2.

I add a new acl for split-tunnel Vpnclient and it also works well.

access-list 103 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

access-list 103 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 103 permit ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

WILLIAM STEGMAN · ‎10-25-2006

that command is enabled on both ends. I took a look at my crypto maps access list for the tunnels, and the remote access vpn traffic is included there. I haven't had a chance to remove it and test, but could that be a problem?

WILLIAM STEGMAN · ‎10-25-2006

i've adjusted the crypto access list to NOT include any traffic from the remote access VPN to the site to site tunnel network and vice versa. Tested, but still no connectivity.