10-24-2006 11:55 AM - edited 02-21-2020 02:41 PM
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
10-24-2006 08:37 PM
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 ?
10-25-2006 01:49 AM
hello,
Do you know whether the feature can work well on pix 6.x and Router IOS
10-25-2006 03:36 AM
pix 6.x no it is supported from min 7.x , no such restriction in IOS u can do this routers without any hassles.
10-26-2006 02:43 AM
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?
11-03-2006 04:41 AM
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.
11-06-2006 02:50 AM
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
10-25-2006 04:07 AM
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?
10-25-2006 11:24 AM
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.
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