Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Site to Site VPN with third site via Frame Relay

Hi there,

I have a site to site VPN (not over internet but securing a WLAN) and it’s working fine.

190.99.99.0/24 192.99.99.0/24

PIX A -> PIX B----LAN

|

|

(192.99.99.100)3640---1700(194.99.99100)

I cannot pass data from PIX A to the subnet at 194.99.99.0. There is connectivity from PIX-B to the router @ 194.99.99.100. I have included the subnet 194.99.99.0 in the access lists in PIX A as I thought that traffic from that network would also have to be included for encryption but it made no diff. There is a route from PIX A (inside interface) to 192.99.99.100 for 194.99.99.0 traffic.

Any ideas?

Regards

12 REPLIES
Gold

Re: Site to Site VPN with third site via Frame Relay

the subnet 194 needs to be included on both pix a and pix b for no-nat and crypto acls.

e.g.

on pix a,

access-list no_nat permit ip 190.99.99.0 255.255.255.0 192.99.99.0 255.255.255.0

access-list no_nat permit ip 190.99.99.0 255.255.255.0 194.99.99.0 255.255.255.0

access-list l2lvpn permit ip 190.99.99.0 255.255.255.0 192.99.99.0 255.255.255.0

access-list l2lvpn permit ip 190.99.99.0 255.255.255.0 194.99.99.0 255.255.255.0

on pix b,

access-list no_nat permit ip 192.99.99.0 255.255.255.0 190.99.99.0 255.255.255.0

access-list no_nat permit ip 194.99.99.0 255.255.255.0 190.99.99.0 255.255.255.0

access-list l2lvpn permit ip 192.99.99.0 255.255.255.0 190.99.99.0 255.255.255.0

access-list l2lvpn permit ip 194.99.99.0 255.255.255.0 190.99.99.0 255.255.255.0

also routing needs to be considered. on pix a, routes pointing to subnet 192 and 194 are required; on pix b, routes pointing to subnet 190 and 194 are required; on router 1700, routes pointing to subnet 190 and 192 are required.

New Member

Re: Site to Site VPN with third site via Frame Relay

thx. i did include the subnet as indicated. will try again. which interface is the route added to on pix a inside or outside? how does pix know to route the destination subnet in that tunnel? the 1700 has a default route to the 3640 which is our gateway of last resort and from there i have a route for 190.99.99.0 to pix b - when traffic for 190.99.99.0 arrives at pix b will pix be know to route it in the tunnel?

New Member

Re: Site to Site VPN with third site via Frame Relay

the above solution worked. thank you. the next problem i have is accessing the internet. we have a isa proxy on the subnet of pix b @ 192.99.99.105 which is the default gateway to the internet. we have a very specific banking application that requires a direct connection to the internet, how would i handle this at pix a - use the any option in the access list? or add a default route routing all traffic to our gateway of last resort @ 192.99.99.100?

Gold

Re: Site to Site VPN with third site via Frame Relay

so the next requirement is to allow direct internet access for host at 190.99.99.0, right?

assuming the pix a outside interface is connected the internet already, then all required are nat/global and default route on the outside interface.

e.g.

global (outside) 1 interface

nat (inside) 0 access-list no_nat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

route outside 0.0.0.0 0.0.0.0

New Member

Re: Site to Site VPN with third site via Frame Relay

nope the pix @ 190.9.99.0 is connected to a WLAN (point to point) i'm using the ipsec tunnel to secure it as the wireless bridges only support wep. internet access is @ 192.99.99.0. the proxy server is 192.99.99.105 and that is a isa2004 box connected to the internet (X2 NIC's. 192.99.99.100 is our gatway of last resort.i can gain internet access at 190.99.99.0 if using the proxy settings in the browser but we have a banking application that requires port 12000-12015 (TCP) to have direct access to the internet. thus i was thinking if i encrpyt all outbound traffic from 190.99.99.0 going out and encrypt all traffic coming out from the other pix?

Gold

Re: Site to Site VPN with third site via Frame Relay

please excuse me for misunderstanding. with this scenario, i guess you've got the concept already and it is to tunnel everything for 190.99.99.0.

e.g.

on pix a,

access-list no_nat permit ip 190.99.99.0 255.255.255.0 any

access-list l2lvpn permit ip 190.99.99.0 255.255.255.0 any

on pix b,

access-list no_nat permit ip any 190.99.99.0 255.255.255.0

access-list l2lvpn permit ip any 190.99.99.0 255.255.255.0

Gold

Re: Site to Site VPN with third site via Frame Relay

just wondering how you go.

New Member

Re: Site to Site VPN with third site via Frame Relay

hi there. i was just working on this now. I tried what you said and the tunnel works, but it still doesn't let me send traffic to the internet. i don't know if there is a routing problem. The Gateway of Last Resort (192.99.99.100) is on the local pix side (i've attached configs), the machine that connects to the internet is a isa2004 server @ 192.99.99.105, from the remote pix i can connect to the isa server. one thing i did notice is that i cannot ping the remote pix inside int from the 192.99.99.0 subnet, but that's not important. just need to be able to get traffic from 190.99.99.0 to internet without proxy.

Gold

Re: Site to Site VPN with third site via Frame Relay

both local and remote pix crypto acls are "permit ip any any", assuming the local pix is dedicated to the ipsec over wireless for subnet 190, then there should be no drama. by applying "permit ip any any" as the crypto acl on the local pix, all traffic received from the local pix inside net will be encrypted and sent to the remote pix via the ipsec tunnel.

on the local pix, the current route statements:

route outside 0.0.0.0 0.0.0.0 192.99.99.100 1

route inside 194.99.99.0 255.255.255.0 192.99.99.100 1

the first entry should be pointing to the inside rather than outside as the host 192.99.99.100 is connected to the pix inside net.

e.g.

route outside 190.99.99.0 255.255.255.0 192.168.0.12

route inside 0 0 192.99.99.100

on the remote pix, the current default gateway is 192.99.99.100. it should be 192.168.0.9, which is the local pix outside interface that is directly connected over wireless.

e.g.

route outside 0 0 192.168.0.9

on the 192.99.99.100 router, there would be some sort of nat/pat configured for traffic destined for the internet or outside.

e.g.

ip nat inside source route-map nonat interface overload

route-map nonat permit 10

match ip address 101

in case there is a route-map for no-nat configured, the subnet 190 needs to be included as well.

further a route for subnet 190 pointing to local pix needs to be configured on 192.99.99.100 router.

e.g.

ip route 190.99.99.0 255.255.255.0 192.99.99.99

lastly, do "de ic t" on both local and remote pix, then kick off a ping from a subnet 190 host to the internet. the output on both pixes should provide more insight.

New Member

Re: Site to Site VPN with third site via Frame Relay

i did a dry run today at site and i can pass data from remote pix to local lan and local pix, can ping from PDM on local pix to ip's on remote network, but i cannot pass data from ip's on local lan (197.99.99.0) to remote pix. local pix also connects to internet. i've ammended legal ip's as per the business policy. for life of me i can't see why data would not go from local lan to remote pix lan, however goes from remote pix network to local pix network. i've attached the config of local pix. also has a client vpn config which is working fine.

Gold

Re: Site to Site VPN with third site via Frame Relay

it would be better if you run the command "debug icmp trace" on both local and remote pix, then kick off a ping from remote host to the internet.

the output will provide the insight as which device is the trouble maker.

e.g.

7199639: ICMP echo-request from inside:192.168.1.51 to 192.168.2.150 ID=512 seq=6401 length=40

7199640: ICMP echo-reply from outside:192.168.2.150 to 192.168.1.51 ID=512 seq=6401 length=40

7199641: ICMP echo-request from inside:192.168.1.51 to 192.168.2.150 ID=512 seq=6657 length=40

7199642: ICMP echo-reply from outside:192.168.2.150 to 192.168.1.51 ID=512 seq=6657 length=40

7199643: ICMP echo-request from inside:192.168.1.51 to 192.168.2.150 ID=512 seq=6913 length=40

7199644: ICMP echo-reply from outside:192.168.2.150 to 192.168.1.51 ID=512 seq=6913 length=40

7199645: ICMP echo-request from inside:192.168.1.51 to 192.168.2.150 ID=512 seq=7169 length=40

7199646: ICMP echo-reply from outside:192.168.2.150 to 192.168.1.51 ID=512 seq=7169 length=40

11: ICMP echo-request from outside:192.168.1.51 to 192.168.2.150 ID=512 seq=6401 length=40

12: ICMP echo-reply from inside:192.168.2.150 to 192.168.1.51 ID=512 seq=6401 length=40

13: ICMP echo-request from outside:192.168.1.51 to 192.168.2.150 ID=512 seq=6657 length=40

14: ICMP echo-reply from inside:192.168.2.150 to 192.168.1.51 ID=512 seq=6657 length=40

15: ICMP echo-request from outside:192.168.1.51 to 192.168.2.150 ID=512 seq=6913 length=40

16: ICMP echo-reply from inside:192.168.2.150 to 192.168.1.51 ID=512 seq=6913 length=40

17: ICMP echo-request from outside:192.168.1.51 to 192.168.2.150 ID=512 seq=7169 length=40

18: ICMP echo-reply from inside:192.168.2.150 to 192.168.1.51 ID=512 seq=7169 length=40

as shown, the top bit is the output from the local pix and the bottom bit is the output from the remote pix. this is generated from live boxes and there is an lan-lan vpn between the two.

now, let's go back to your scenario. imagine the local there is no echo-reply from the local pix, the issue is probably related to routing; alternatively, if there is no echo-reply from the remote pix, but on the local pix, that means the crypto config on the local pix is the issue.

New Member

Re: Site to Site VPN with third site via Frame Relay

there is def connectivity between the pix's. i can ping hosts on the 192.99.99.0 subnet from inside the pix on 197.99.99.0, however i cannot telnet from a host on the 197.99.99.0 to a host on 190.99.99.0. Yet if i telnet from a host on the 190.99.99.0 subnet i can access hosts on the 197.99.99.0, it only a one way access from 190.99.99.0 to 197.99.99.0, thus i'm not sure but if there was a routing problem then i wouldn't be able to access hosts on the 197.99.99.0 subnet from 190.99.99.0. when i run crypto debug on both no errors are reported. Odd thing is that i can telnet from 190 to 197 but not ping.

201
Views
0
Helpful
12
Replies
CreatePlease to create content