02-14-2007 09:04 AM - edited 03-03-2019 03:45 PM
I'm trying to setup a GRE tunnel to share EIGRP route across a linux firewall. I found a document on using IPSec with GRE across a firewall to distribute EIGRP:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009438e.shtml
I'm trying to share routes between our WAN core and our LAN core across the linux firewall that sits between them. The WAN is a 10.64.32.x interface on the firewall and the LAN is a 192.168.10.x on the firewall, so I'm pretty sure I'm forced to build the GRE tunnel. Does the encryption have to be configured like the document says? I'm assuming so.
Also, we actually have two LAN cores running HSRP. Would I just build individual GRE tunnels from the WAN core to both LAN cores and let EIGRP handle failover or would that be a bad idea?
Solved! Go to Solution.
02-15-2007 09:36 AM
Jake
Thanks for posting the current details. It helped me recognize that I had not read carefully when I responded about the access list. You misunderstood what route to filter and I did not catch it. You do not want to deny the subnet of the tunnel itself (192.168.16.0) but want to deny the tunnel destination address. So on router 1 you would want this:
access-list 80 deny 192.168.10.0 0.0.0.255
and on router 2 you would want this:
access-list 80 deny 10.64.32.0 0.0.1.255
That is a bit of an odd mask (especially for an interface whose comment says WAN) but it matches what you have in the config.
The access list still needs the permit any, and the distribute-list still needs to be in on tunnel0.
HTH
Rick
02-14-2007 02:11 PM
Ok, so I built it in a test environment, but not having luck. What am I doing wrong?
Router1:
ip subnet-zero
no ip source-route
!
!
no ip domain-lookup
ip domain-name penson.cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
! Incomplete
set peer 10.64.32.77
set transform-set strong
match address 120
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.64.32.77
crypto map vpn
!
interface FastEthernet0/0
description to_firewall
ip address 192.168.10.55 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
crypto map vpn
!
interface FastEthernet0/1
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
speed 100
full-duplex
!
router eigrp 64
network 192.168.10.0
network 192.168.16.0
no auto-summary
!
ip default-gateway 192.168.10.4
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.4 name default_to_fw
no ip http server
!
access-list 130 permit gre host 192.168.10.55 host 10.64.32.77
Router 2:
ip subnet-zero
!
!
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 192.168.10.55
set transform-set strong
match address 130
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 192.168.10.55
crypto map vpn
!
interface FastEthernet0/0
description to_WAN
ip address 10.64.32.77 255.255.254.0
speed 100
full-duplex
crypto map vpn
!
interface Serial0/0
no ip address
shutdown
no fair-queue
!
interface BRI0/0
no ip address
encapsulation hdlc
shutdown
!
interface FastEthernet0/1
description private_lan
ip address 10.1.1.2 255.255.255.0
speed 100
full-duplex
!
router eigrp 64
network 10.0.0.0
network 192.168.10.0
network 192.168.16.0
no auto-summary
!
ip default-gateway 10.64.32.33
ip classless
ip route 0.0.0.0 0.0.0.0 10.64.32.33 name default_to_fw
ip route 10.1.1.0 255.255.255.0 FastEthernet0/1
ip http server
!
access-list 130 permit gre host 10.64.32.77 host 192.168.10.55
From 192.168.10.55 I can ping 10.64.32.77 and vice versa. However, the EIGRP routes are not being shared. The 10.1.1.0/24 route is not showing up on 192.168.10.55
Any ideas?
02-14-2007 02:17 PM
Hmm, looks like the tunnel isn't working. From 192.168.16.1 I cannot ping 192.168.16.2 even though the tunnel shows up/up. It was working earlier. The ping just worked because of the default route... I'm confused. I followed the Cisco document and it worked at first. Weird.
02-14-2007 05:31 PM
Jake
The thing that stands out is that you have a problem in your crypto map. Notice the second line that says "incomplete". This is because the crypto map says to use access list 120. But from what you posted it looks like there is no access list 120 and there is access list 130.
crypto map vpn 10 ipsec-isakmp
! Incomplete
set peer 10.64.32.77
set transform-set strong
match address 120
It is not as serious, but depending on the version of code that you are running you probably should have the crypto map only on the physical interface and not on the tunnel interface. In older code (which was the basis for the example that you followed) the crypto map needed to be on both the tunnel and the physical interface. In more recent code it should be only on the physical interface.
Fix those things and let us know if it works better.
HTH
Rick
02-15-2007 08:12 AM
Thanks Rick. That worked to get the tunnel up and running, but now I'm trying to get EIGRP running across the tunnel and I get the following errors:
1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is up: new adjacency
fake_wan_core#
1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is down: holding time expired
fake_wan_core#
1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is up: new adjacency
fake_wan_core#
1w0d: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
1w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is down: interface down
Here is the current config:
Router 1:
ip subnet-zero
!
!
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 192.168.10.55
set transform-set strong
match address 130
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 192.168.10.55
!
interface FastEthernet0/0
description to_WAN
ip address 10.64.32.77 255.255.254.0
speed 100
full-duplex
crypto map vpn
!
interface Serial0/0
no ip address
shutdown
no fair-queue
!
interface BRI0/0
no ip address
encapsulation hdlc
shutdown
!
interface FastEthernet0/1
description private_lan
ip address 10.1.1.2 255.255.255.0
speed 100
full-duplex
!
router eigrp 64
network 10.0.0.0
network 192.168.16.0
no auto-summary
!
ip default-gateway 10.64.32.33
ip classless
ip route 0.0.0.0 0.0.0.0 10.64.32.33 name default_to_fw
ip route 10.1.1.0 255.255.255.0 FastEthernet0/1
ip http server
!
access-list 130 permit gre host 10.64.32.77 host 192.168.10.55
Router 2:
ip subnet-zero
no ip source-route
!
!
no ip domain-lookup
ip domain-name penson.cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 10.64.32.77
set transform-set strong
match address 130
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.64.32.77
!
interface FastEthernet0/0
description to_firewall
ip address 192.168.10.55 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
crypto map vpn
!
interface FastEthernet0/1
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
speed 100
full-duplex
!
router eigrp 64
network 192.168.10.0
network 192.168.16.0
no auto-summary
!
ip default-gateway 192.168.10.4
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.4 name default_to_fw
no ip http server
!
access-list 130 permit gre host 192.168.10.55 host 10.64.32.77
02-15-2007 08:27 AM
Jake
The problem of recursive routing in fairly common when working with GRE tunnels. It happens frequently when the tunnel destination is advertised by the dynamic routing protocol running through the tunnel. The issue is that it makes it look like the best way to get to the tunnel destination is to go THROUGH the tunnel. When that happens the IOS does a temporary shutdown of the tunnel.
There are a couple of ways that you can fix this. You could configure a distribute list that denies the address of the tunnel destination (and permits other addresses) and put the distribute list in EIGRP inbound on the tunnel. Or you could configure a static route for the tunnel destination. The administrative distance of the static route will be better than the distance of EIGRP and so even though EIGRP may advertise the address of the destination through the tunnel, the static route will be used.
HTH
Rick
02-15-2007 08:51 AM
Thanks, Rick. I added the following and it seems to have cleared up the recursive routing, but now the 10.1.1.0 network is not propgating:
access-list 80 deny 192.168.16.0 0.0.0.255
router eigrp 64
no auto-summary
distribute-list 80 in
network 192.168.10.0
network 192.168.16.0
and on the other route:
access-list 80 deny 192.168.16.0 0.0.0.255
router eigrp 64
no auto-summary
distribute-list 80 in
network 10.0.0.0
network 192.168.16.0
02-15-2007 09:07 AM
Jake
I believe that you need to filter the updates received on the tunnel but not on the physical interface. I suggest that you change the config to this:
distribute-list 80 in tunnel0
Also in the access list 80 after you deny what you do not want, then you need to permit other routes so you should add:
access-list 80 permit any
HTH
Rick
02-15-2007 09:20 AM
That caused the recursive routing to come back. here are the configs:
Router 1:
p subnet-zero
!
!
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 192.168.10.55
set transform-set strong
match address 130
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 192.168.10.55
!
interface FastEthernet0/0
description to_WAN
ip address 10.64.32.77 255.255.254.0
speed 100
full-duplex
crypto map vpn
!
interface Serial0/0
no ip address
shutdown
no fair-queue
!
interface BRI0/0
no ip address
encapsulation hdlc
shutdown
!
interface FastEthernet0/1
description private_lan
ip address 10.1.1.2 255.255.255.0
speed 100
full-duplex
!
router eigrp 64
network 10.0.0.0
network 192.168.16.0
distribute-list 80 in Tunnel0
no auto-summary
!
ip default-gateway 10.64.32.33
ip classless
ip route 0.0.0.0 0.0.0.0 10.64.32.33 name default_to_fw
ip route 10.1.1.0 255.255.255.0 FastEthernet0/1
ip http server
!
access-list 80 deny 192.168.16.0 0.0.0.255
access-list 80 permit any
access-list 130 permit gre host 10.64.32.77 host 192.168.10.55
Router 2:
ip subnet-zero
no ip source-route
!
!
no ip domain-lookup
ip domain-name penson.cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set strong esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 10.64.32.77
set transform-set strong
match address 130
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 192.168.16.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.64.32.77
!
interface FastEthernet0/0
description to_firewall
ip address 192.168.10.55 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
crypto map vpn
!
interface FastEthernet0/1
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
speed 100
full-duplex
!
router eigrp 64
network 192.168.10.0
network 192.168.16.0
distribute-list 80 in Tunnel0
no auto-summary
!
ip default-gateway 192.168.10.4
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.4 name default_to_fw
no ip http server
!
no logging trap
logging source-interface FastEthernet0/0
access-list 80 deny 192.168.16.0 0.0.0.255
access-list 80 permit any
access-list 130 permit gre host 192.168.10.55 host 10.64.32.77
02-15-2007 09:36 AM
Jake
Thanks for posting the current details. It helped me recognize that I had not read carefully when I responded about the access list. You misunderstood what route to filter and I did not catch it. You do not want to deny the subnet of the tunnel itself (192.168.16.0) but want to deny the tunnel destination address. So on router 1 you would want this:
access-list 80 deny 192.168.10.0 0.0.0.255
and on router 2 you would want this:
access-list 80 deny 10.64.32.0 0.0.1.255
That is a bit of an odd mask (especially for an interface whose comment says WAN) but it matches what you have in the config.
The access list still needs the permit any, and the distribute-list still needs to be in on tunnel0.
HTH
Rick
02-15-2007 10:37 AM
You're the man, Rick. That worked. This is a test environment, but for production I'll actually build a tunnel with a /30 from the WAN core to the LAN core across a firewall. That should work just as well as this /24, right? just change up the subnet masks?
Also, not sure if you're familiar, but I'll be building these tunnels from our WAN core across a firewall to two LAN cores running in HSRP. 2 Questions. First, is the encryption part of this tunnel necessary for EIGRP? and Second, would I just build seperate tunnels from the WAN core to each of the LAN cores and how will that work w/ HSRP?
Thanks a ton. You rock.
02-15-2007 10:49 AM
Jake
Thanks for marking this discussion as solved. (and for the rating) It makes the forum more useful when people can read about a problem and know that they will be able to read the thing that solved the problem.
Yes changing the masks should not be a problem.
The encryption part is not necessary for EIGRP. The important part for EIGRP is the point to point tunnel. Whether the traffic is encrypted or not does not matter to EIGRP. I dont know that it makes much difference to the firewall. As long as the firewall permits the traffic through it should work (whether the firewall is permitting ESP or permitting GRE - check with the firewall administrators and see if it matters to them).
I would advise building separate tunnels to each LAN core. I am not sure that HSRP affects things very much. If you just build the tunnels and let everything take default values then you should get mostly equal cost routes to all the destinations. If you have set the LAN cores so that one is generally preferred as the active router in HSRP you might want to increase the delay of the tunnel to the standby so that the EIGRP metrics through the tunnel to the active router look better than routes to the standby router.
HTH
Rick
02-15-2007 10:56 AM
I know we use our LAN cores in HSRP for both fault tolerance and load sharing. Half our VLANs are on one and the other half on the other. Also, since its EIGRP from WAN to LAN I'll go ahead and keep the encryption :).
Thanks again for the help.
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