Cisco Routing Help

iaind · 1 May 2009 at 12:43

OK I'm a bit of a Cisco n00b so I'm sure this is really obvious

I've got a Fortigate firewall at our main site and several Cisco 877 ADSL routers at remote sites set up with VPNs to the fortigate. All works fine, although I want to be able to route between 2 of the remote sites. This is the config I'm working with:

show run
Building configuration...

Current configuration : 2634 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname ****
!
boot-start-marker
boot-end-marker
!
enable secret ****
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.13.1 192.168.13.20
ip dhcp excluded-address 192.168.13.200 192.168.13.254
!
ip dhcp pool DHCP
network 192.168.13.0 255.255.255.0
dns-server 172.16.0.1 172.16.0.7
default-router 192.168.13.254
option 150 ip 172.17.10.1
!
!
no ip domain lookup
!
!
!
!
!
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ****
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer ****
set transform-set strong
match address 102
crypto map vpn 20 ipsec-isakmp
set peer ****
set transform-set strong
match address 103
!
!
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface FastEthernet0
no cdp enable
!
interface FastEthernet1
no cdp enable
!
interface FastEthernet2
no cdp enable
!
interface FastEthernet3
no cdp enable
!
interface Vlan1
ip address 192.168.13.254 255.255.255.0
ip access-group 100 in
ip nat inside
ip virtual-reassembly
ip route-cache flow
ip tcp adjust-mss 1452
!
interface Dialer0
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
ppp authentication chap callin
ppp chap hostname ****
ppp chap password 7 ****
crypto map vpn
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0
!
no ip http server
no ip http secure-server
ip nat inside source list 105 interface Dialer0 overload
!
access-list 102 permit ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 103 permit ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 permit ip 192.168.13.0 0.0.0.255 any
snmp-server community public RO
snmp-server community private RW
snmp-server enable traps tty
!
control-plane
!
banner login ^CAuthorized access only!
Disconnect IMMEDIATELY if you are not an authorized user!^C
!
line con 0
no modem enable
line aux 0
line vty 0 4
password 7 106358150900425B08
login
!
scheduler max-task-time 5000
end

So I've added a route to both sites (ip route 192.168.11.0 255.255.255.0 172.16.254.255 and the equivalent at the other end - 254.255 is the firewall's internal address) but it still seems to try routing traffic destined for the other site over the net. What am I missing? :confused:

howler · 1 May 2009 at 14:10

172.16.254.25 - is that the address that the VPN terminates?

with static routes the route you put in needs to be the next hop

iaind · 1 May 2009 at 14:13

172.16.254.255 - yes it is, that's the next hop

howler · 1 May 2009 at 14:25

odd, you're doing a traceroute from the router right? And the first hop is the Dialer interface?

an you ping 172.16.254.255?

L33 · 1 May 2009 at 15:01

You quote your static route "ip route 192.168.11.0 255.255.255.0 172.16.254.255", but looking in your config, nowhere have you stated that 192.168.11.0 is interesting traffic for either of the tunnels?
VPN tunnels don't work with routes, but rather with interesting traffic which is defined in your ACLs.
172.16.245.255 is also a broadcast address so you should really try and avoid assigning it to an interface, could end up causing you all sorts of headaches!

iaind · 1 May 2009 at 15:07

L33 said:
You quote your static route "ip route 192.168.11.0 255.255.255.0 172.16.254.255", but looking in your config, nowhere have you stated that 192.168.11.0 is interesting traffic for either of the tunnels?
VPN tunnels don't work with routes, but rather with interesting traffic which is defined in your ACLs.
172.16.245.255 is also a broadcast address so you should really try and avoid assigning it to an interface, could end up causing you all sorts of headaches!

Aha I thought it would be something like that. So just create another access list and add it to the "match address" part of the tunnel config

I know it could be a broadcast address - I didnt set it up and it would be a bit of a pain to change it. It was done by a large "consultancy" company before I even started here...

Skidilliplop · 1 May 2009 at 15:49

As above, you have to apply an ACL to the VPN to specify which traffic it allows. Also quite useful for cutting out the crap and limiting to the services it's actually going to be used for.

As for the 172.16.245.255 address that seems to be in the middle of an address range which is a bizarre place to put it. Given the mask for that subnet and assuming by the fact you're only using VPN as a WAN link it's not an aggregate route for lots of other subnets, i'd have expected it to be 0.1 or .255.254 :confused:

iaind · 1 May 2009 at 15:58

Its an odd one, our switches (which are used as the default gateway in our main site to route between data and voice vlans) have the IP 172.16.254.254

Seems to be completely random.. as all the core network was set up by a "a technology driven, business focused, Microsoft infrastructure solutions house with a strong UK wide reputation for excellence" - google that if you're interested about who it is!

Skidilliplop · 1 May 2009 at 16:04

Microsoft infrastructure solutions house

Herein lies the problem. Microsoft engineers haven't got a clue about network infrastructure as a rule.

I've recently had to add a subnet to an AD setup because despite it always existing it hadn't contained a DC so they didn't bother adding it to AD. Which defies common sense and causes headaches later.

What can I say they're consultants.... their job is to CONSULT i.e to CON you and inSULT your intelligence.

iaind · 1 May 2009 at 16:10

Yes I would never rely on consultants - I'd much rather figure things out for myself - bring on the CCNA bootcamp though!

The same company did an exchange 03 implementation at the last company I worked at. They configured 3 local mirrors, labeled "system" "data" and "transaction logs". The system volume contained the system and transaction logs, the data contained the edb files and the transaction logs contained the stm files.... so they dont even understand the fundamentals of Microsoft technologies!

Skidilliplop · 1 May 2009 at 16:25

iaind said:
Yes I would never rely on consultants - I'd much rather figure things out for myself - bring on the CCNA bootcamp though!

The same company did an exchange 03 implementation at the last company I worked at. They configured 3 local mirrors, labeled "system" "data" and "transaction logs". The system volume contained the system and transaction logs, the data contained the edb files and the transaction logs contained the stm files.... so they dont even understand the fundamentals of Microsoft technologies!

If you're messing with VPN and multilayer switching, you'll wanna fastrack to CCNP. CCNA only covers basic VLANing, static/dynamic routing and some ACLs as far as practical stuff goes.

Though in my view Cisco is just a benchmark for skills, in the real world i'd go with Extreme networks kit every time

L33 · 1 May 2009 at 16:33

iaind said:
Aha I thought it would be something like that. So just create another access list and add it to the "match address" part of the tunnel config

I know it could be a broadcast address - I didnt set it up and it would be a bit of a pain to change it. It was done by a large "consultancy" company before I even started here...

Spot on

Sounds like you know what you're doing more than the consultancy company and you self-confessed to being new to cisco stuff

Shout back if you get stuck!

iaind · 1 May 2009 at 17:02

Skidilliplop said:
If you're messing with VPN and multilayer switching, you'll wanna fastrack to CCNP. CCNA only covers basic VLANing, static/dynamic routing and some ACLs as far as practical stuff goes.

Though in my view Cisco is just a benchmark for skills, in the real world i'd go with Extreme networks kit every time

I think CCNP might be a bit far - I'm reasonably proficient in networking/vpns/routing etc, its more the cisco "way" I need to get used to. We're only a small network and CCNA bootcamp courses seem to run to about 2k, I cringe to think what a CCNP would cost!

Curiosityx · 1 May 2009 at 19:00

Code:

ip nat inside source list 105 interface Dialer0 overload
!
access-list 102 permit ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 103 permit ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 permit ip 192.168.13.0 0.0.0.255 any

This is partly the problem, You need to use a route map to specify which traffic you want to exempt from NAT. Your also missing some elements.

Code:

access-list 102 permit ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 102 permit ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
!
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 105 deny ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 permit ip 192.168.13.0 0.0.0.255 any
!
ip nat inside source route-map nonat interface Dialer0 overload
!
route-map nonat permit 10
 match ip address 105

Example Config

Code:

crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key SeCr3TK!Y address **IP Address**
!
!
crypto ipsec transform-set 3dessha esp-3des esp-sha-hmac 
!
crypto map vpncryptomap 10 ipsec-isakmp 
 description ****** Link to " " *****
 set peer **IP Address**
 set security-association lifetime seconds 86400
 set security-association idle-time 28800
 set transform-set 3dessha 
 set pfs group2
 match address SplitTunnelvpnTraffic
!
ip nat inside source route-map noNat interface Dialer1 overload
!
ip access-list extended natExempt
 deny   ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
 deny   ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
 permit ip 192.168.13.0 0.0.0.255 any
!
ip access-list extended SplitTunnelvpnTraffic
 permit ip 192.168.13.0 0.0.0.255 172.16.0.0 0.0.255.255
 permit ip 192.168.13.0 0.0.0.255 172.17.0.0 0.0.255.255
!
route-map noNat permit 10
 match ip address natExempt
!
interface Dialer1
 description WAN Interface
 crypto map vpncryptomap 
 mtu 1492
!
interface Vlan1
 description LAN Interface
 ip address **IP Address**
 ip virtual-reassembly
 ip tcp adjust-mss 1452
!

Skidilliplop said:
Herein lies the problem. Microsoft engineers haven't got a clue about network infrastructure as a rule.

I take offence at that, i have an MCSE and an MCSA, dont tarnish us all with the same brush

HTH

iaind · 4 Jun 2009 at 14:26

Firstly, apologies for the thread ressurection, have only just started looking at this again.

Thanks for the suggestion CuriosityX, I've used that as a starting point as a config. I've managed to get our voice and data down one tunnel now, which is something!

Setup is a bit like this

192.168.15.0/24 (Remote) --------172.16.0.0/16 and 172.17.0.0/26 (Main) --------- 192.168.14.0/24 (Remote)

Config of the 15.0 site is:

Building configuration...

Current configuration : 2655 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname th-zenadsl
!
boot-start-marker
boot-end-marker
!
enable secret ****
enable password ****
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip source-route
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.15.1 192.168.15.20
!
ip dhcp pool DHCP
network 192.168.15.0 255.255.255.0
default-router 192.168.15.1
dns-server 172.16.0.1 172.16.0.7
option 150 ip 172.17.10.1
!
!
ip name-server 212.23.3.100
ip name-server 212.23.6.100
!
!
!
!
!
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key **** address ****
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer ****
set transform-set strong
match address VPNTraffic
!
!
!
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
description $ES_WAN$
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Vlan1
description $FW_INSIDE$
ip address 192.168.15.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Dialer0
description $FW_OUTSIDE$
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname ****
ppp chap password 0 ****
crypto map vpn
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 192.168.14.0 255.255.255.0 172.16.254.250
!
ip http server
no ip http secure-server
ip nat inside source route-map noNAT interface Dialer0 overload
!
ip access-list extended VPNTraffic
permit ip 192.168.15.0 0.0.0.255 172.16.0.0 0.0.255.255
permit ip 192.168.15.0 0.0.0.255 172.17.0.0 0.0.255.255
permit ip 192.168.15.0 0.0.0.255 192.168.14.0 0.0.0.255
!
access-list 105 deny ip 192.168.15.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 105 deny ip 192.168.15.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 105 permit ip 192.168.15.0 0.0.0.255 any
access-list 105 deny ip 192.168.15.0 0.0.0.255 192.168.14.0 0.0.0.255
route-map noNAT permit 10
match ip address 105
!
!
control-plane
!
!
line con 0
no modem enable
line aux 0
line vty 0 4
password ****
login
!
scheduler max-task-time 5000
end

The 14.0 site is pretty much the same in reverse. I still cant see 14.0 from 15.0 and vice versa - a trace to either just times out at the local router, despite the fact I've specified a route.
Oddly, I cant ping 172.16 addresses from the router console, but can ping www addresses, dont know if thats normal with VPNs or not...
Any ideas before I start tearing out my hair?

iaind · 4 Jun 2009 at 14:49

Spotted when I posted that the access list for the NAT exemption was in the wrong order - corrected that but with the same result!

Skidilliplop · 4 Jun 2009 at 16:02

Wildcard mask is wrong in your ACL for 172.17. It should be the inverse mask of a /26 according to your notes above the config. which it's not. It's currently the inverse mask of a /16.

Not sure if Subnetworks on the end of VPNs are interpereted as directly attached. You might need to add a static route to that location also as although it has a route entry for 192.168.14 it will do a recursive lookup for the 172.16 network and fail if no entry is found, however if it shows in sh IP route as connected then it should be fine.
But check the masks etc and also check to make sure it's not sumarising the 192.168 routes because they're not contiguous. It shouldn't do this with no dynamic routing configured but check it.
Just be sure each router has a route entry for every other subnet in the LAN.

iaind · 4 Jun 2009 at 16:11

Skidilliplop said:
Wildcard mask is wrong in your ACL for 172.17. It should be the inverse mask of a /26 according to your notes above the config. which it's not. It's currently the inverse mask of a /16.

Not sure if Subnetworks on the end of VPNs are interpereted as directly attached. You might need to add a static route to that location also as although it has a route entry for 192.168.14 it will do a recursive lookup for the 172.16 network and fail if no entry is found, however if it shows in sh IP route as connected then it should be fine.
But check the masks etc and also check to make sure it's not sumarising the 192.168 routes because they're not contiguous. It shouldn't do this with no dynamic routing configured but check it.
Just be sure each router has a route entry for every other subnet in the LAN.

/26 was a typo, they're both /16 subnets

sh ip route doesnt show the 172.16 network so guessing thats the problem - what would I need to add?

Skidilliplop · 4 Jun 2009 at 17:17

I think you would put "IP route 172.16.0.0 255.255.0.0 dialer0"

And the ACL will stuff it over the VPN and the remote router will then have the locally attached route/next in line routing entry and know where to put it.

I always thought that it learned the subnets attached to a VPN tunnel. Though tbh I don't use VPNs much as in medium - large business LES10s/RF links are the norm for inter site, also most of the ones I've done used dynamic routing anyway.
Won't hurt to fiddle, that route deffo needs to be there someway or other. If it's failing at the local gateway it's probably because the recursive route lookup isn't finding 172.16 and is firing it out the default to nowhere.

iaind · 4 Jun 2009 at 18:26

I'm sure i tried that in my fiddling but i'll try it again just in case.

Beginning to think setting them up as a "mesh" would be easier than hub and spoke...