IPSec woes -- trouble after installing firewalls between IPSec endpoints

[tprendergast]

Hi all,

I recently had to install some pixs between our internet router and some internal routers in one branch office. A quick overview:

internet router <--> Pixes in FO pair <-NAT-> Routers <--> Switch Fabric

Basically, the internal routers used to have public-facing interfaces with IPs from our external block. I had 2 IPSec GRE tunnels running on one of them and had users connecting in from home via 1721s. Since we had very little space, I had to public address the pixes, readdress the internal routers, and go from there.

So, here's where I am -- my tunnels show up/up, but I cannot talk to anything internally addressed from the home routers. This all worked *prior* to me having to readdress the internal routers to get the firewalls in. I'll be posting all three configs (firewall, internal router, home router) in cleaned up formats as text attachments. Note, also, that I have left the pix wide open forwarding traffic in until I can resolve this issue. I'll reapply my more restrictive ACLs when this is fixed.

Just as a point of reference:

200.200.200.200 -- home router static IP (from ISP)

100.100.100.100 -- The public ip that *was* on our outside interface of our internal router, which is now on the pix as a static to the new ip of the router.

172.18.201.0/24 -- the new internal network i created to re-address the routers to be behind the inside interface of the pix

The home-example is the 1721 remote router, the inside-router-example is the internal router, and the firewall-example is our pix 525 that was just installed.

Let me know if there is more I should include...

Thanks in advance!

-Tim

[ehirsel]

What does the route table state for the home router, and the internal routers? Are you sure that all proper EIGRP routes are being propogated properly? I think that GRE still sees the tunnel endpoints using the old address, and that IPSEC addresses are nat'ed properly by the PIX, but not the GRE tunnel headers, since the pix is not the ipsec peer.

If that is the case, then maybe one of these items can help:

1. Use the proxyarp feature of the pix code and go back to using the old ip addresses on the routers. The one feature of ios that you can take advantage of, is that even if the ipsec traffic terminates on interface FastEthernet0/0, the crypto map can use a loopback address as the source address. That is the ike and esp headers will substitute loopback 0's ip address on the frame header. So you can still use private ip addresses on the router-to-pix, use the same subnet between pix and provider router. And config the pix to proxyarp on behalf of the inside routers.

2. You can make the pix become the ipsec peer, and process gre on the internal router. The remote routers will continue to do both. Using this, you will have to reconfig the home routers to have a different ipsec peer than a gre tunnel peer, however the pix can perform nat for gre traffic destined to and from the gre peers. You may be able to bypass nat for gre traffic, if the pix will become the ipsec peer as it can trust that the remote site has properly authenticated itself, thus there may no reason to use nat for gre traffic anyway.

Let me know if this helps.

As a side note to option #1:

Say the public subnet is 100.100.100.96/28. On the pix use 100.100.100.101 as the outside ip address. You can config the pix to do proxyarp as follows:

sysopt proxyarp outside

You would still have your static, but they would look like this:

static (inside, outside) 100.100.100.100 100.100.100.100 netmask 255.255.255.255

And you would have a route statement like this:

route inside 100.100.100.100 172.18.201.4

[tprendergast]

That seems to put me on the right track, but I need to clarify a few things first (to make sure I've got it entirely).

In order for this to work in the current configuration, I'd need to put the old ip of the router on the loopback, add the crypto map to the loopback, change the static translation on the pix to not nat the address, and add a route for that non-natted packet to the internal ip of the router. The router would then see the IP matches that of the loopback and accept the packet for decryption/processing. The pix would need the sysopt proxyarp outside command enabled for this to work as well.

One question in that case -- does this affect the other traffic coming in to 100.100.100.100 that was going to be processed on the 172.18.201.4 interface after NAT/PAT?

Thanks for your earlier response, I assigned points.

-Tim

tim@haxorwear.com (email me if you like to discuss)

[ehirsel · Accepted solution]

The route statement on the pix will need the subnet mask:

route inside 100.100.100.100 255.255.255.255 172.18.201.4

After you change the static, don't forget to do a clear xlate on the pix: clear xlate local 172.18.201.4

You do not need to assign the crypto map to the loopback int. What you do is this in global config mode on the router:

crypto map mapname local-address loobackx, where x is the loopback number and mapname is your crypto map name (homevpn, I think it was). If local-address is not the correct option, just enter crypto map ? at the global config prompt and you should see help text that mentions about assigning an ip address as the source for the ipsec traffic.

Notes:

1. On the router the tunnel interface will use the same loopback interface as its source too. Having the crypto map applied on the actual phy interface helps with the routing so you don't have to create route maps to route to the loopback to apply ipsec processing.

This should take care of the GRE and IPSec traffic. Was there any other traffic that I need to consider?

Take care to archive the current configs on the internal router and pix before making these changes to allow for easier rollback in case things go awry.

[tprendergast]

Thanks for all your help, Ed. I got everything back in shape!

Points and solution marked as resolved.

-Tim