IPsec with ip nat inside source static

[Geoffrey Marissen]

Hello guys and girls,

I have this problem, it’s a brain cracker to me.. so I hope you guys or girls can help me out here...

Have a company with a HQ and a branch.

The HQ has a subnet of 10.1.18.0 /24

The branch has a subnet of 10.2.18.0/24

There is a IPsec between the HQ and the branch.

There is a static NAT inside from WAN to LAN.

The problem, I can’t get to the IP addresses on the port numbers which have a static NAT, which are on the HQ side, from the branch side.

Let’s assume that the IPsec is working fine...

Below the config part of the IPsec and the NAT.

!

crypto map VPN_IPSEC 20 ipsec-isakmp

 match address IPSEC_BRANCH

!

!

interface Dialer1

 crypto map VPN_IPSEC

!

!

ip nat inside source list PERMIT_NAT interface Dialer1 overload

ip nat inside source static tcp 10.1.18.11 1352 x.x.x.x 1352 route-map NO_NAT_10.2.18.0

ip nat inside source static tcp 10.1.18.11 80 x.x.x.x 80 route-map NO_NAT_10.2.18.0

ip nat inside source static tcp 10.1.18.11 443 x.x.x.x 443 route-map NO_NAT_10.2.18.0

ip nat inside source static tcp 10.1.18.14 3389 x.x.x.x 3389 route-map NO_NAT_10.2.18.0

ip nat inside source static tcp 10.1.18.11 25 x.x.x.x 25 route-map NO_NAT_10.2.18.0

ip route 0.0.0.0 0.0.0.0 Dialer1

!

ip access-list extended DENY_NAT_10.2.18.0

 deny   ip 10.2.18.0 0.0.0.255 10.1.18.0 0.0.0.255

 deny   ip 10.1.18.0 0.0.0.255 10.2.18.0 0.0.0.255

ip access-list extended IPSEC_BRANCH

 permit ip 10.1.18.0 0.0.0.255 10.2.18.0 0.0.0.255

ip access-list extended PERMIT_ANY

 permit ip any any

ip access-list extended PERMIT_NAT

 deny   ip 10.1.18.0 0.0.0.255 10.2.18.0 0.0.0.255

 permit ip 192.168.1.0 0.0.0.255 any

 permit ip 10.1.18.0 0.0.0.255 any

!

!

route-map NO_NAT_10.2.18.0 deny 10

 match ip address DENY_NAT_10.2.18.0

!

route-map NO_NAT_10.2.18.0 permit 20

 match ip address PERMIT_ANY

!

My opinion is: because there is a static NAT it will put the NAT rules in his “NAT Translations” shown by the show ip nat translations

Pro     Inside global          Inside local       Outside local      Outside global

tcp 87.x.x.227:25  10.1.18.11:25              ---                          ---

tcp 87.x.x.227:80  10.1.18.11:80              ---                          ---

tcp 87.x.x.227:443 10.1.18.11:443           ---                         ---

tcp 87.x.x.227:1352 10.1.18.11:1352      ---                         ---

tcp 87.x.x.227:3389 10.1.18.14:3389      ---                            ---

when I realy send some traffic from branche to HQ on port 25 I get this NAT translation.

Pro     Inside global          Inside local       Outside local           Outside global

tcp 87.x.x.227:25  10.1.18.11:25     10.2.18.20:25           10.2.18.20:25          

The NAT goes before the route(??), so the router send the traffic back over the outside interface Di1 and not trough the IPsec tunnel.

The ACL for interesting traffic and the deny in the ACL for NAT overload isn’t enough. Therefore I have configured a routemap on the ip NAT static rule.

But this doesn’t solve the problem.

Hope you guys or girls have some clue, or can help me brainstorm to get to a good solution..

[Jon Marshall]

The issue is the return traffic from the server.

When it gets to the router it does a route lookup and sees the 10.2.18.x IP is reachable via the WAN interface, then the source IP is translated to the public IP and then the crypto map acl is checked.

But your crypto map acl does not include the public IP so the traffic is not sent down the tunnel.

The solution is the one you have used but your route map configuration is wrong.

In the route map deny statement the acl you reference should be using a permit statement ie.

permit ip 10.1.18.0 0.0.0.255 10.2.18.0 0.0.0.255

note you only need that one line in your acl.  

The permit statement in your route map is fine although using "any any" in the acl with NAT can sometimes lead to unexpected results.

The reason it isn't working as you have it is because of route map logic ie. you have a deny statement and the acl you are referencing is also using a deny so that simply moves the packet onto the second permit statement.

If you change the acl to use a permit statement as above then because the route map clause is a deny and the acl is a permit it will stop processing the route map and you should see it work.

Obviously once you modify the acl in your route map make sure you clear any existing translations before retesting.

Finally if that is your real public IP in the translation output can you replace it with 89.x.x.227 as that is enough to give us the idea and this is a public forum.

Jon

[Geoffrey Marissen]

John,

First of all, thanks for the warning... I've looked trough the config for any WAN IP... but forgot the show ip NAT translations...

Second, thanks for the anwser. I will test the changes you suggested and will keep you posted.

[Geoffrey Marissen]

Jon,

Thank you, works fine after changing the ACL rule to permit.