ip summary-address eigrp ... services lost during VPN

[sherman.melik]

Hello,

I have an interesting issue and I'll simplify as much as possible.  Any help/idea would be appreciated.

Topology:  FW --vpn-->R1---R2*---*R3---R4

FW: Site A firewall.  vpn establishes from this device.

R1:  Site A, IP's range 10.100.x.x/16  variably sub-netted within.

R2*---*R3:  A point to point ethernet circuit between sites, IP range 10.200.0.0/30.

R4:  Site B; IP's range 10.60.x.x/16  variably sub-netted within.

R1:

router eigrp 1
 network 10.100.0.0 0.0.255.255
 redistribute static

ip route 0.0.0.0 0.0.0.0 10.100.0.2
ip route 10.101.0.0 255.255.255.0 10.100.0.2  <--static route for VPN

R2:

router eigrp 1
 network 10.100.0.0 0.0.255.255
 network 10.200.0.0 0.0.0.3

R3:

router eigrp 1
 network 10.60.0.0 0.0.255.255
 network 10.200.0.0 0.0.0.3

R4:

router eigrp 1
 network 10.60.0.0 0.0.255.255

Task is simple, apply "ip summary-address eigrp 1 10.100.0.0 255.255.0.0" to the outbound interface of R2 (toward R3, site B), and apply "ip summary-address eigrp 1 10.60.0.0 255.255.0.0" to the outbound interface of R3 (toward R2, site A).  IP Routing tables look great!  PING reply in both directions!  Fully functional.

Then I IPSec VPN... I can still ping addresses, traceroute, etc... but, I lose all capability of telnet, ssh, and remote server console between sites?!?

I did modify all network commands to include a simple "network 10.0.0.0".  Confirmed "no auto summary". Applied "no ip redirects" to the summary interfaces. Ensured that no eigrp route was "named".  No access-list, distribution list, nor route-map exists that would deny or prevent - only while a VPN session is active.  Removing the summary-address commands allows VPN to fully function as intended.

Other observations: 

1. Services, when VPN, appears to fail only when the R3 summary is applied - it appears the R2 summary does not cause an issue. At least none observed.
2. EIGRP Routers do sync with their neighbor properly when summary is applied/removed/applied/removed...lol
1. %PARSER-5-CFGLOG_LOGGEDCMD: User:admin  logged command:ip summary-address eigrp 1 10.60.0.0 255.255.0.0
2. %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.200.0.1 (GigabitEthernet0/0/0) is resync: summary configured
3. All routes are either properly summarized, and/or present in the ip routing tables, including the static redistributed routes.

Now as for the VPN configuration, it functions without issue... that is until I apply a summary.  So I'm not sure if I'm missing a VPN command, or if this is a routing issue due to the static redistribution.  As stated above... any help/ideas will be appreciated.

[Richard Bradfield]

Can you do a " show ip route eigrp" for each router and post

thanks

Richard

[sherman.melik]

Richard,

Thank you for responding.  Please see attached.  "pre sum" are the ip route prior to applying the summary statement.  "post" are the ip route after applying the summary statement.

Hope you see something I didn't.

[Richard Bradfield]

Hi,

 your routing looks good.

So is the problem you can't access the routers from the remote side of the VPN tunnel?

if you can ping everything ok, but not telnet/ssh then couuld be something to do with the "source-interface" you are using to telnet/ssh

[sherman.melik]

Everything works fine at the moment... I have backed off the summary commands... no issue to report.

Only when applying summary address, and then only utilizing VPN am I unable to telnet, ssh, or remote desktop to any device (switch, router, server, etc...), beyond R2.  Yet, I can ping, traceroute, arp, etc to those same devices.

Because I'm trying to clarify, let me put it another way...  with summary addressing applied and utilizing my locally connected PC and PUTTY, all is well.  Then I go home and VPN, I can do what I want on my local network; to any device; but I cannot reach my remote devices, as described above, until I remove the summary statement on R3 - then, all is well.

"source-interface", to my knowledge unlikely, but then I never claim to know everything!  Would you please elaborate more on how a source-interface may be causing my problems and perhaps how to investigate/check?

I'm really at a loss on this, and truly appreciate your thoughts and suggestions.

[Richard Bradfield]

Ok, beginning to see the problem.

if you have the "auto-summary" command under "Router eigrp 1" then you don't normally need the " ip summary-address commands"

Router eigrp 1

auto-summary

Have you tried that?

Re "source-interface" this is to do with routers, I wasn't sure if your VPN was a site to site, if so on the remote router if try and ping connect to a device in the tunnel from the remote vpn router will by default use the Internet address, which would fail, so have to say the source interface is the vlan that is in the VPN tunnel.

[sherman.melik]

Sorry Richard... negitive on both counts.  Again, thank you for assisting.

Auto-summary does not apply here; as eigrp only auto summarizes at the classful boundary.  As I'm not leaving the 10.0.0.0/8 network, eigrp would never auto summarize.  Thus, my only choice is to manually summarize.

Source-interface is, unfortunatly, not an issue.  Without summarizing, VPN is fully functional, and as you saw from the routing tables, the static/redistributed vpn network is propagated throughout.  But, it was a good suggestion.

Now... I may have located the issue and solution, but need to wait for a down-time to confirm.  Unbeknownst to me, I learned that eigrp is enabled upon the firewall, shown in the original post.  And, part of that route configuration includes a "route outside 10.60.0.0 0.0.255.255 1"  <== why? I don't know, but since I'm attempting to inject a 10.60.0.0/16 summary from the inside... well, this isn't going to work is it - the outside route will take presidance (AD 1 vs AD 90), and communication with the remote site will fail.

Let you know, after I have a down-time for testing.

[Richard Bradfield]

hey it looks like you have found the problem,

Looks like somebody made a mistake should have been route inside not outside.

glad you have fixed the problem

regards

Richard