06-27-2015 01:10 AM - edited 03-05-2019 01:46 AM
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..
06-27-2015 09:59 AM
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
06-27-2015 09:59 AM
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.
06-29-2015 03:39 AM
Jon,
Thank you, works fine after changing the ACL rule to permit.
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