Solved: EIGRP through plain IPsec tunnel?

Federico Coto Fajardo · ‎08-03-2010

Hi All,

I've always been under the impression that plain IPsec only pass IP unicast traffic through the tunnel.

When I've needed to pass non-unicast or non-IP traffic, I've created a IPsec with GRE or VTI.

But, I am currently at a customer's site where all the EIGRP routes are being exchanged between two sites that communicate across a single plain IPsec tunnel.

I've added/modified/deleted routes on both sides, and the changes reflect on the other's routing table.

The neighbors are not statically configured on the router, the EIGRP configuration is just ''no auto-summary'' and then '' network 172.16.0.0''

My question is...

How come all the EIGRP traffic is passing through the tunnel with no problems?

Both are 2811s running 12.4(18)

Thank you for any help!

Federico.

Richard Burts · ‎08-03-2010

Federico

I do indeed believe that this is the case. It is pretty clear from the additional information that you posted that these two routers are directly connected (in this case connected via FastEthernet) and that the connecting interfaces are running EIGRP, so the EIGRP HELLOs are sent out the FastEthernet interfaces. The access list does not have permits for EIGRP so there is no effort to encrypt the HELLOs and they are sent in the clear. So the routers become neighbors and the EIGRP updates are sent over the FastEthernet interfaces. The data traffic to the destinations that are learned is sent over the FastEthernet interfaces and when the data traffic matches the access list then it is encrypted by IPSec.

HTH

Rick

HTH

Rick

View solution in original post

Richard Burts · ‎08-03-2010

Federico

I think that it is true that a plain IPSec tunnel passes only unicast IP traffic (and therefore not EIGRP or OSPF). Perhaps if we had some more information we might be able to provide better answers to explain this. Perhaps as a start you could post the output of show ip interface brief so we can verify the interfaces and the addressing and then post at least a partial output of show ip route which shows some prefixes learned from the neighbor over the IPSec tunnel.

I have a customer who has an implementation that produces pretty much the outcome that you describe. They have a connection to a peer over a Frame Relay connection. They have an IPSec tunnel configured that operates over the Frame Relay to protect sensitive business data that is being transmitted. The access list used in the crypto map has permits for the data traffic but does not have permits for the routing protocol traffic. So EIGRP runs over the Frame Relay link, establishes its neighbor relationship over the Frame Relay, and advertises prefixes over the Frame Relay, but the data traffic over the Frame Relay is protected by IPSec. I wonder if you have a similar type of implementation.

HTH

Rick

HTH

Rick

Federico Coto Fajardo · ‎08-03-2010

Richard,

Thank you for your response.

I am sending a little bit more of information:

Router#1:

r1-azul#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.150.89   YES NVRAM up                    up
FastEthernet0/1            172.16.3.10     YES NVRAM up                    up

r1-azul#sh cry isa sa
dst src state conn-id slot status
172.16.150.92 172.16.150.89 QM_IDLE 1 0 ACTIVE

r1-azul#sh access-l 100
Extended IP access list 100
    10 permit ip any 172.16.120.0 0.0.0.255 (1994448984 matches)
    20 permit ip any 172.16.121.0 0.0.0.255 (642983461 matches)
    30 permit ip any 172.16.122.0 0.0.0.255 (10717798 matches)

r1-azul#sh ip eigrp neigh
IP-EIGRP neighbors for process 3333
H   Address                 Interface       Hold Uptime   SRTT   RTO Q Seq
                                            (sec)         (ms)       Cnt Num
2   172.16.3.9              Fa0/1             12 02:19:05    4   200 0 90990
4   172.16.150.92           Fa0/0             11 5d02h      51   459 0 3742
0   172.16.3.11             Fa0/1             10 3w5d        3   200 0 214562
1   172.16.3.13             Fa0/1             10 4w4d        3   200 0 51066
3   172.16.3.12             Fa0/1             11 18w4d       2   200 0 21359
5   172.16.3.1              Fa0/1             14 20w0d       3   200 0 32732

Router#2:

r2-azul#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.150.92   YES NVRAM up                    up
FastEthernet0/1            172.16.120.1    YES NVRAM up                    up

r2-azul#sh cry isa sa
dst src state conn-id slot status
172.16.150.92 172.16.150.89 QM_IDLE 1 0 ACTIVE

r2-azul#sh access-l 100
Extended IP access list 100
    10 permit ip 172.16.120.0 0.0.0.255 any (71106709 matches)
    20 permit ip 172.16.121.0 0.0.0.255 any (18842025 matches)
    30 permit ip 172.16.122.0 0.0.0.255 any (16477 matches)

r2-azul#sh ip eigrp neigh
IP-EIGRP neighbors for process 3333
H   Address                 Interface       Hold Uptime   SRTT   RTO Q Seq
                                            (sec)         (ms)       Cnt Num
1   172.16.150.100          Vl1                9 00:02:33   10   282 0 264731
0   172.16.150.89           Fa0/0             11 5d02h      56   336 0 22247

r2-azul#sh ip route
Gateway of last resort is 172.16.150.89 to network 0.0.0.0

D    172.17.0.0/16 [90/176128] via 172.16.150.89, 00:02:56, FastEthernet0/0
     172.16.0.0/16 is variably subnetted, 9 subnets, 4 masks
D       172.16.0.0/16 [90/175616] via 172.16.150.89, 00:02:56, FastEthernet0/0

As you can see, R2 is learning via EIGRP the networks of the remote site R1.

The interesting traffic is specified as any on the corporate site (there are no denies in the crypto ACL)

The underlying connection between this two routers is a wireless link.

I understand what you say about learning the EIGRP routes not through the tunnel, but do you think this is the case?

Federico.

Richard Burts · ‎08-03-2010

Federico

I do indeed believe that this is the case. It is pretty clear from the additional information that you posted that these two routers are directly connected (in this case connected via FastEthernet) and that the connecting interfaces are running EIGRP, so the EIGRP HELLOs are sent out the FastEthernet interfaces. The access list does not have permits for EIGRP so there is no effort to encrypt the HELLOs and they are sent in the clear. So the routers become neighbors and the EIGRP updates are sent over the FastEthernet interfaces. The data traffic to the destinations that are learned is sent over the FastEthernet interfaces and when the data traffic matches the access list then it is encrypted by IPSec.

HTH

Rick

HTH

Rick

Federico Coto Fajardo · ‎08-03-2010

Richard,

Now that I read what you posted; I find it perfect sense! I was breaking my head over this!

I couldn't believe I didn't thought of this before, but that's why I like posting here :-)

Thank you very much indeed!!!

Federico.

Richard Burts · ‎08-03-2010

Federico

I am glad that my explanation helped you to solve your question. Thank you for using the marking system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know from the marking that they will read responses which did lead to a solution.

HTH

Rick

HTH

Rick

Jitendriya Athavale · ‎08-04-2010

but it is possible to send ospf over ipsec without gre by converting multicast to unicast

http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/products_configuration_example09186a00804acfea.shtml#c4

Federico Coto Fajardo · ‎08-04-2010

Thank you, I've seen that.

I was confused because I was seeing EIGRP traffic exchanged between two sites connected through a plain IPsec tunnel without realizing that they were directly connected so the actual EIGRP updates were being exchanged without going through the tunnel.

Federico.

cciehemant · ‎03-19-2014

Hello Rick,

The above example shows that traffic that is allowed explicitly by access list but if I say permit ip any any at both sides then also the directly connected links will share the eigrp packet without being encrypted and form adjacency ?

Regards,

Hemant

noushadnoushad · ‎09-09-2018

It is working for me even with ip any any.