Routing across Frame-Relay network to VPN?

peterkley · ‎12-22-2005

I have about 10 sites on a frame network, connecting to the main site thru S0/0. There are 4 sites using DSL to connect to the WAN ip of the main site, using tunnels. The main site has E0/0 for the WAN link and a public IP, and FA1/0 for the LAN.

There is a VPN on the LAN at 10.159.140.2 (FA1/0 is 10.159.140.1)

I have this entry to route traffic to a specific web site that is on the VPN:

ip route 10.28.0.0 255.255.0.0 10.159.140.2

If I type in 10.28.98.35 in a web browser on the LAN, traffic works just fine.

However, anywhere outside the LAN, either on the frame or via tunnel, a traceroute shows it hitting the main site ip and quitting. Any suggestions?

Here's a condensed version of what's on the main site router (I assume the problem is there since the trace does hit it). I also edited out the public addresses to protect the innocent!

interface Tunnel0

description Citris Heights

ip address 10.159.100.21 255.255.255.252

ip access-group 102 in

no ip directed-broadcast

ip nat inside

ip summary-address eigrp 10 10.159.0.0 255.255.0.0

tunnel source Ethernet0/0

tunnel destination xxx.xxx.xxx.xxx

tunnel key 15146

!

interface Ethernet0/0

ip address xxx.xxx.xxx.xxx 255.255.255.248

ip access-group 101 out

ip directed-broadcast

ip nat outside

no ip route-cache

no ip mroute-cache

no cdp enable

!

interface Serial0/0

description ASI Circuit ID XXX

bandwidth 128

no ip address

no ip directed-broadcast

encapsulation frame-relay

no ip route-cache

no ip mroute-cache

logging event subif-link-status

logging event dlci-status-change

no fair-queue

service-module t1 timeslots 1-24

frame-relay traffic-shaping

frame-relay lmi-type ansi

!

interface Serial0/0.16 point-to-point

description Orangevale

bandwidth 56

ip address 10.159.100.61 255.255.255.252

no ip directed-broadcast

ip nat inside

ip summary-address eigrp 10 10.159.0.0 255.255.0.0

no ip route-cache

no ip mroute-cache

no cdp enable

frame-relay interface-dlci 16

class 56kcir

!

interface FastEthernet1/0

ip address 10.159.140.1 255.255.255.0

ip access-group 103 in

no ip directed-broadcast

ip nat inside

no ip route-cache

no ip mroute-cache

no cdp enable

!

router eigrp 10

redistribute static

passive-interface Ethernet0/0

passive-interface FastEthernet1/0

network 10.0.0.0

no auto-summary

eigrp log-neighbor-changes

!

ip nat inside source list 1 interface Ethernet0/0 overload

ip nat inside source static tcp 10.159.188.14 22 interface Ethernet0/0 22

ip nat inside source static tcp 10.159.188.13 3389 interface Ethernet0/0 40411

ip nat inside source static interface Fastethernet1/0 8080 interface Serial0/0.21 8080

ip classless

ip route 10.28.0.0 255.255.0.0 10.159.140.2

ip route 0.0.0.0 0.0.0.0 <outside internet>

!

peterkley · ‎12-22-2005

Here is the rest...

!

map-class frame-relay 56kcir

no frame-relay adaptive-shaping

frame-relay cir 56000

frame-relay bc 1000

frame-relay mincir 56000

frame-relay priority-group 1

!

map-class frame-relay 384kcir

no frame-relay adaptive-shaping

frame-relay cir 384000

frame-relay bc 3840

frame-relay be 0

frame-relay mincir 384000

frame-relay priority-group 1

!

map-class frame-relay 128kcir

no frame-relay adaptive-shaping

frame-relay cir 128000

frame-relay bc 1280

frame-relay be 0

frame-relay mincir 128000

frame-relay priority-group 1

!

map-class frame-relay 384cir

no frame-relay adaptive-shaping

access-list 1 permit 10.159.0.0 0.0.255.255

access-list 101 deny ip any 10.0.0.0 0.255.255.255

access-list 101 permit ip any any

access-list 102 permit ip 10.159.135.0 0.0.0.255 any

access-list 102 permit ip 10.159.100.20 0.0.0.3 any

access-list 102 deny ip any any

access-list 103 deny udp any any eq netbios-ns

access-list 103 deny udp any any eq netbios-dgm

access-list 103 permit ip any any

access-list 104 permit ip 10.159.153.0 0.0.0.255 any

access-list 104 permit ip 10.159.100.64 0.0.0.3 any

access-list 104 deny ip any any

access-list 105 permit ip 10.159.180.0 0.0.0.255 any

access-list 105 permit ip 10.159.100.88 0.0.0.3 any

access-list 105 deny ip any any

access-list 106 permit ip 10.159.167.0 0.0.0.255 any

access-list 106 permit ip 10.159.100.56 0.0.0.3 any

access-list 106 deny ip any any

access-list 150 permit udp any any range 5000 5070

access-list 150 permit udp any range 5000 5070 any

access-list 150 permit udp any any eq 5567

access-list 150 permit udp any eq 5567 any

access-list 150 permit tcp any any eq 5566

access-list 150 permit tcp any eq 5566 any

access-list 150 permit tcp any any eq 5570

access-list 150 permit tcp any eq 5570 any

access-list 150 permit udp any any eq 16384

access-list 150 permit udp any eq 16384 any

priority-list 1 protocol ip high list 150

mheusinger · ‎12-23-2005

Hi,

unfortunately I am not so sure about source and destination IPs, but are you sure your access-lists do allow the traffic you intend to send through the tunnel?

As a step in troubleshooting remove the access-lists from the tunnel and other interfaces (reapply them afterwards!). Is the problem then still there?

Hope this helps

Martin

Richard Burts · ‎12-23-2005

There are some things about Peter's explanation of the situation and of the problem that I have not completely understood. But I wonder if his problem is in the configuration of the VPN. I notice that there is no VPN configuration in the configuration parts that he posted. He says that the VPN is on 10.159.140.2 and I wonder what kind of device that is, and if it might be another router. I would guess from the symptoms that the VPN configuration on 10.159.140.2 might permit traffic with a source address in the subnet of that interface but not permit traffic with source address of other parts of the network. And of course there is the possibility that the device at 10.159.140.2 (or devices on the other end of the VPN) do not have routes back to the addresses of the other part of his network.

Perhaps Peter can comment on this.

HTH

Rick

HTH

Rick

peterkley · ‎12-23-2005

Yes, the VPN is a separate device. Sadly I don't have any information on what that device is or how it is set up.

But your email helped me to realize that the problem is more likely in the VPN rather than the route tables. I will also remove the access-lists that apply and see what happens.

Thanks!