Port forwarding and IPSEC VPN's

[t.vandenheuvel]

Hello,

I have a multi-site network setup, each site containing a Cisco 2801 which takes care of internet routing and VPN setup.
Each site has it's own private subnet and is connected to the main site using IPSEC site to site VPN through regular internet connections.  Additionaly, for dial-in users the router at the main site has an L2TP crypto map.  This is all working perfectly fine.

Now for SQL Server management purposes we need to expose a port to certain external IP's on the outside network so I created the necessary firewall exceptions and IP NAT rule.  This also is working fine.

Unfortunately, as soon as I create the NAT entry, the users on the remote private networks connected through the PTP VPN's loose their ability to connect to the private server port that also has been forwarded to the outside.  The IP is still reachable, just the one forwarded port isn't.

Above does not affect dial-in VPN users.  Since they connect through a vt interface and all PTP VPN's are just connecting using crypto map address matching I assume this might be somehow involved.

Any suggestions on this?

[Cristian Matei]

Hi,

    Can you share your NAT config? Most probably you're using static NAT or static PAT, which means the private server traffic is always NAT'ed regardless of the destination (outside network/Internet or remote private networks through your VPN tunnels). Your solution would be to configure static policy PT, so specify that the server is visible on the outside as NAT'ed only for specific destination( use extended ACL and match your private server traffic to the external network, call the ACL in a route-map, and configure static NAT/PAT with the route-map attached and the keyword "reversible" configured, to force the NAT policy both ways).

Regards,

Cristian Matei.

[t.vandenheuvel]

Hi,

NAT config:

ip nat inside source list NAT interface GigabitEthernet0/0.34 overload
ip nat inside source static tcp 192.168.5.36 26000 *public ip* 26000 extendable

ip access-list extended NAT
 remark *** UTR-VPN Subnets ***
 deny   ip any 192.168.8.0 0.0.7.255
 remark *** AMS-VPN Subnets ***
 deny   ip any 192.168.16.0 0.0.7.255
 remark *** EUN-VPN Subnets ***
 deny   ip any 172.24.0.0 0.0.255.255
 deny   ip any 192.168.56.0 0.0.0.255
 remark *** Translated Subnets ***
 permit ip 192.168.0.0 0.0.0.255 any
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip 192.168.4.0 0.0.0.127 any
 permit ip 192.168.5.0 0.0.0.127 any
 permit ip 192.168.5.160 0.0.0.31 any
 remark *** DEV Subnets ***
 permit ip 172.16.0.0 0.0.0.255 any
 permit ip 172.16.1.0 0.0.0.255 any

Have been wondering if it had to do with the exclusion of VPN subnets in the SQL translation since since the private subnets also need to be exclued out of the "regular internet" NAT, but haven't been able to produce a working config yet. 

I'll look into the route maps to get it working with the ACL's.

[Georg Pauwen · Accepted solution]

Hello,

the config should look something like below. The access list specifies the external hosts you want the NAT to be enabled for:

ip nat inside source static tcp 192.168.5.36 26000 *public ip* 26000 route-map NAT_RM reversible
!
ip access-list extended POLICY_NAT_ACL
permit ip host 192.168.5.36 host x.x.x.x
permit ip host 192.168.5.36 host y.y.y.y
permit ip host 192.168.5.36 host z.z.z.z
!
route-map NAT_RM permit 10
match ip address POLICY_NAT_ACL

[Cristian Matei · Accepted solution]

Hi,

    Based on below line, that traffic is always NAT'ed, regardless of the destination and regardless of your ACL config for NAT overload, as static NAT overrides dynamic NAT.

 ip nat inside source static tcp 192.168.5.36 26000 *public ip* 26000 extendable

   Remove the above line and replace it with:

!
ip access-list POLICY_STATIC_NAT

   permit ip host private-server host public-server

!

route-map POLICY_STATIC_NAT permit 10

   match ip address POLICY_STATIC_NAT

!

ip nat inside source static tcp 192.168.5.36 26000 x.x.x.x 26000 route-map POLICY_STATIC_NAT reversible

Regards,

Cristian Matei.

[t.vandenheuvel]

Thank you Georg and Christian,

Adding the route map indeed solves the problem and makes sense.

Since access control is already taken care of at the firewall ACL applied to the public connection I reversed the SQL-NAT access list to deny the VPN subnets and allow all the rest:

ip access-list extended SQL-NAT
remark *** Deny VPN Subnets ***
deny ip host 192.168.5.36 192.168.8.0 0.0.7.255
deny ip host 192.168.5.36 192.168.16.0 0.0.7.255
remark *** Permit all the rest ***
permit ip host 192.168.5.36 any

Best Regards,

Tom