Solved: NAT on ASA 5510 | Nat'ed address not reachable from internal net

fabian.hahn · ‎02-27-2013

Hi,

we have set up an ASA to connect our external(provider)- and internal networks. A NAT-rule forwards IMAP-SSL traffic from the external address to the internal mail server. This works well for users in the Internet and from Wlan.

From the internal network we can not reach the IMAP-server with the external IP adress.

What is the best way to configure this?

Attached all commands that I think might be relevant.

The external IP address ist 88.88.116.212

The IP address of the mail-server is 10.10.10.158

I appreciate any help you could give us on this problem.

Thanks,

Fabian

ASA Version 8.4(4)1

!

hostname firewall-01-1

domain-name intern.ourdomain.com

!

interface Ethernet0/0

no nameif

no security-level

no ip address

!

interface Ethernet0/0.6

vlan 6

nameif airport

security-level 0

ip address 88.88.117.1 255.255.255.128

ospf cost 10

!

interface Ethernet0/0.11

vlan 11

nameif telekom

security-level 0

ip address 88.88.116.4 255.255.255.240

ospf cost 10

!

interface Ethernet0/0.22

vlan 22

nameif dmz

security-level 0

ip address 88.88.118.171 255.255.255.0

ospf cost 10

!

interface Ethernet0/1

description Internal net

nameif inside

security-level 100

ip address 10.10.10.129 255.255.255.0

!

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

object network telekom

subnet 88.88.116.0 255.255.255.244

object network f2

host 10.10.10.158 ! Mail-Server

object network mx2.ourdomain.com

host 81.169.154.107

object network imap-ssl.ourdomain.com

host 88.88.116.212 ! Extnl. IP

object-group service zugriff_imap

service-object icmp echo

service-object icmp echo-reply

service-object tcp destination eq imap4

object-group network pat-all

network-object object pat-airport

network-object object pat-dmz

network-object object pat-telekom

access-list telekom_access_in extended permit object-group zugriff_imap any object imap-ssl.ourdomain.com

access-list telekom_access_in extended permit tcp object mx2.ourdomain.com object imap-ssl.ourdomain.com eq smtp

access-list telekom_access_in extended permit tcp any object f2 eq 993

access-list telekom_access_in extended permit tcp object mx2.ourdomain.com object f2 eq smtp

access-list airport_access_in extended permit tcp any object f2 eq 993

access-list amdraht_2_splitTunnelAcl standard permit 10.10.10.0 255.255.255.0

nat (inside,telekom) source static NETWORK_OBJ_10.10.10.0_24 NETWORK_OBJ_10.10.10.0_24 destination static

!

object network f2

nat (inside,telekom) static imap-ssl.ourdomain.com service tcp 993 993

object network dhcp_inside

nat (inside,telekom) dynamic 88.88.116.11

object network dhcp_inside_dmz

nat (inside,dmz) dynamic 88.88.118.200

object network f2_nat_airport

nat (inside,airport) static imap-ssl.ourdomain.com service tcp 993 993

object network f2_to_mx2

nat (inside,telekom) static imap-ssl.ourdomain.com service tcp smtp smtp

access-group airport_access_in in interface airport

access-group telekom_access_in in interface telekom

route telekom 0.0.0.0 0.0.0.0 88.88.116.1 1

timeout xlate 3:00:00

timeout pat-xlate 0:00:30

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

service-policy global_policy global

jocamare · ‎02-27-2013

Here,

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml

View solution in original post

jocamare · ‎02-27-2013

Here,

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml

fabian.hahn · ‎02-28-2013

Hi Jocamare,

thanks for the fast response. This solution sounds like what we need. Will try to configure this.

Best,

Fabian

Jouni Forss · ‎02-28-2013

Hi,

Notice though that the provided link contains configurations related to the old configuration format (7.2 software)

While you seem to be using 8.4(4) which NAT format is totally different

- Jouni

fabian.hahn · ‎03-05-2013

Hi Journi,

we implemented your solution and it seems to work - half-way. We are now receiving packets from the internal net, but the connection is not established. We see the following messages on the ASA:

%ASA-6-302014: Teardown TCP connection 144030715 for inside:10.10.10.124/51457 to inside:10.10.10.158/993 duration 0:00:30 bytes 0 SYN Timeout

We found some comments about configuring a Non-State option for this intern/intern NAT but were not able to configure this. Could you help with a config that will work for 8.4?

Thanks a million!

Fabian

jocamare · ‎03-05-2013

nat (inside,inside) source dynamic any interface destination static F2-PUBLIC F2 service F2-SSL F2-SSL

Jouni Forss · ‎03-05-2013

Hi,

I think I mixed up the server IP addresses to wrong objects.

object network F2

host 10.10.10.158

88.88.116.212#sthash.EPLD9CCr.dpuf

88.88.116.212#sthash.EPLD9CCr.dpu

88.88.116.212#sthash.EPLD9CCr.dp

object network F2-PUBLIC

host 88.88.116.212

object network LAN

subnet 10.10.10.0 255.255.255.0

object network LAN-NAT

subnet 10.10.20.0 255.255.255.0

nat (inside,inside) source static LAN LAN-NAT destination static F2-PUBLIC F2

object service F2-SSL

service tcp destination eq 993

nat (inside,inside) source static LAN LAN-NAT destination static F2-PUBLIC F2 service F2-SSL F2-SSL

I think in both cases it should be fine to NAT the "inside" users to some random NAT network provided its not used in your current network and provided the return traffic from the "inside" hosts get forwarded to the ASA with default route for example

You can naturally replace the source with dynamic PAT as Jocamare suggested. Might even be simpler

I am not 100% sure on the Proxy ARP setting also. Check that you dont have the sysopt command configured that disables proxy ARP on the "inside" interface. What I am wonder is will it mess up the NAT operation OR will the NAT override that setting if present. I havent tested that.

Personally for me this static mapping of 2 networks worked fine also.

- Jouni

Jouni Forss · ‎02-27-2013

Hi,

I think I briefly tested this home with the new software and what I did was

Translate the Server Real IP to the Public IP
Translate the LAN network to some NAT network

I imagine that if you would simply NAT the "inside" host to public IP towards the same interface "inside" the thing wouldnt work

I only quickly tested this before so cant give any guarantee how it would work with your setup. In my home ASA it worked fine.

I had this test setup

2 hosts on the same LAN network
I wanted to reach the other LAN host from the other LAN host with a public IP address and with VNC
I first tried simple "inside" to "inside" NAT. This didnt work.
I created a Twice NAT / Manual NAT which also NATed my connecting hosts original IP address

Configuration was something like this (Using your info in this case)

object network F2

host 88.88.116.212

88.88.116.212#sthash.EPLD9CCr.dpuf

88.88.116.212#sthash.EPLD9CCr.dpu

88.88.116.212#sthash.EPLD9CCr.dp

object network F2-PUBLIC

host 10.10.10.158

object network LAN

subnet 10.10.10.0 255.255.255.0

object network LAN-NAT

subnet 10.10.20.0 255.255.255.0

nat (inside,inside) source static LAN LAN-NAT destination static F2-PUBLIC F2

Though the above doesnt take into account the single port

I think in that case you might have to do the following

object service F2-SSL

service tcp destination eq 993

nat (inside,inside) source static LAN LAN-NAT destination static F2-PUBLIC F2 service F2-SSL F2-SSL

Cant guarantee it will work, can only say it worked in my home ASA5505 (8.4(5)) setup.

Hope this helps

- Jouni

fabian.hahn · ‎05-01-2013

Hi Jouni,

after spending some time trying with different solutions we think we habe an asymetic-routing situation here. The answer is described in https://supportforums.cisco.com/docs/DOC-17810. But we are not succeding to apply this pattern for tcp-state-bypass to our situation. The class, map and ACL are confusing us.

Could you please help us with the configuration, either CLI or in the interface, to enable tcp-state-bypass for the imap-server. This will allow our users to move from the WiFi-Network to the wired network with the configuration they are using from home.

Thanks a million!

Fabian

Jouni Forss · ‎05-01-2013

Hi,

Did you already try this NAT configuration?

object network F2

host 10.10.10.158

88.88.116.212#sthash.EPLD9CCr.dpuf

88.88.116.212#sthash.EPLD9CCr.dpu

88.88.116.212#sthash.EPLD9CCr.dp

object network F2-PUBLIC

host 88.88.116.212

object network LAN

subnet 10.10.10.0 255.255.255.0

object service F2-SSL

service tcp destination eq 993

nat (inside,inside) source dynamic LAN interface destination static F2-PUBLIC F2 service F2-SSL F2-SSL

With this there should really not be a problem with the routing.

- Jouni

fabian.hahn · ‎05-01-2013

Yes, we did. With tcpdump we see first packet but no connection beeing established. The ASA gives us TEARDOWN message. Seems like the problem described in DOC-17810. Did not get the suggested state-bypass configured.

Fabian

Jouni Forss · ‎05-01-2013

Hi,

I dont think the Asymmetric routing is the case here.

Though naturally we havent seen the complete ASA configuration yet.

I would suggest using this configuration to again test the setup and take some command outputs from the ASA

object network F2

host 10.10.10.158

88.88.116.212#sthash.EPLD9CCr.dpuf

88.88.116.212#sthash.EPLD9CCr.dpu

88.88.116.212#sthash.EPLD9CCr.dp

object network F2-PUBLIC

host 88.88.116.212

object network LAN

subnet 10.10.10.0 255.255.255.0

nat (inside,inside) 1 source dynamic LAN interface destination static F2-PUBLIC F2

When the above is configured, this is what is supposed to happen for example

Host 10.10.10.10 on the "inside" queries DNS server for the IP address of the destination server
Host receives a DNS reply telling that the destination server IP address is 88.88.116.212
Host 10.10.10.10 initiates the connection to the destination IP address of 88.88.116.212
When the connection reaches the ASA the following NAT operations will be done
- Host IP address 10.10.10.10 will be NATed to 10.10.10.129
- The destination IP address 88.88.116.212 will be UN-NATed to 10.10.10.158
The connection will head towards the actual host 10.10.10.158 and it will be visible from the source IP address 10.10.10.129
The server 10.10.10.158 will reply to the IP address 10.10.10.129 which will naturally reach the ASA as it holds that IP address
When that connection return traffic reaches the ASA it will use the existing translations and connection table to forward the return traffic back to the host 10.10.10.10
The traffic will go back and forth in normal way

Atleast this is to me how its supposed to work.

I have had no problem configuring this in my own ASA

When you have the above NAT configuration configured you can test the operation with the "packet-tracer" command

packet-tracer input inside tcp 10.10.10.10 12345 88.88.116.212 993

And post the ouput here

- Jouni