10-09-2018 06:46 AM
Hello folks,
I have the following config (IOS 12.3):
A.B.C.13 stands for the outside, public IP, bound on interface Fa0/1.52
x.x.x.n stands for a random public peer that connects to A.B.C.13
y.y.y.n stands for a random public peer that connects to A.B.C.13
z.z.z.n stands for a random public peer that connects to A.B.C.13
interface FastEthernet0/1.52 description *** OUTSIDE *** encapsulation dot1Q 52 ip address A.B.C.13 255.255.255.192 ip access-group ACL_FW_FROM_OUTSIDE in ip nat outside
interface FastEthernet0/1.312 description *** INSIDE *** encapsulation dot1Q 312 ip address 172.19.128.254 255.255.255.0 ip nat inside
ip nat inside source list ACL_NAT_FROM_INSIDE interface FastEthernet0/1.52 overload ip nat inside source static tcp 172.23.10.151 25 A.B.C.13 25 extendable
For me this looks like there is *one* D-NAT configured, translating outside A.B.C.13:25 to 172.23.10.151:25 - this works as expected. However, I have various translations that translate A.B.C.13:443 to the internal host 172.19.128.152:443 as shown in show ip nat translations:
router# show ip nat translations | i 443 tcp A.B.C.13:443 172.19.128.152:443 x.x.x.84:54019 x.x.x.84:54019 tcp A.B.C.13:443 172.19.128.152:443 y.y.y.30:4143 y.y.y.30:4143 tcp A.B.C.13:443 172.19.128.152:443 z.z.z.42:10890 z.z.z.42:10890
Where are these translationes defined?
There is not a single line containing 172.19.128.152 in the running-config.
The only config statement that relates to communication on port 443 is defined in the referenced ACL "ACL_FW_FROM_OUTSIDE":
Extended IP access list ACL_FW_FROM_OUTSIDE 170 permit tcp any host A.B.C.13 eq 443 (149602 matches)
If I delete this line, communication with the service on port 443 (Outlook Web Access) doesn't work anymore (as one would expect). But where is the translation coming from? How does the IOS know to translate A.B.C.13:443 to internal host 172.19.128.152 ?
Thanks in advance for your feedback!
Solved! Go to Solution.
10-12-2018 05:31 AM
Hello Pieter,
it turned out this was something like a "phantom element" in the config. The NAT rules i posted were the only rules defined. After a reboot of the firewall, the translation isn't working anymore. So actual behaviour of the system and running-config are aligned now.
Thanks for your feedback!
10-09-2018 08:21 AM
Hello
You have defined a ACL that incorporates the inside lan network as such dynamic nat is now being used from your internal inside local users.
10-09-2018 11:04 AM
The explanation for your question starts with reviewing the nat configuration for your router
ip nat inside source list ACL_NAT_FROM_INSIDE interface FastEthernet0/1.52 overload
This says that anything from inside going outside should be translated to the outside interface address. The nat entries you are asking about are the result of the configuration (which technically might be referred to as pat rather than nat).
HTH
Rick
10-09-2018 12:01 PM - edited 10-09-2018 12:12 PM
Hello
Just realised that you may be asking why the nat table is showing random tcp ports from the outside towards an inside global address tcp 443 suggesting the session was initiated from the outside - is that correct?
10-10-2018 07:05 AM
Hello Paul,
I'm in fact initiating communication from outside to A.B.C.13:443 and that connection is dest-NATed to the internal host 172.19.128.152:443.
The question is: Where is this mapping coming from? Where is it defined?
The only dest-NAT defined is
ip nat inside source static tcp 172.23.10.151 25 A.B.C.13 25 extendable
- but 172.23.10.151 is not 172.9.128.152. Why am I able to initiate that communication from outside?
Thank you!
10-10-2018 07:46 AM
I'm in fact initiating communication from outside to A.B.C.13:443 and that connection is dest-NATed to the internal host 172.19.128.152:443.
-> I think you make a mistake here.
these NAT's are not related to the test you are making from the outside coming-in
my guess is this is a result of normal processes on the client 172.19.128.152 (in the background like windows-update, defender, smartscreen filter etc) from inside going out.
- disconnect this client
- clear the nat table
and do the test from outside again
10-10-2018 08:12 AM
Hi Peter,
I can just see and experience that my connection from outside (from 37.247.X.206:443) to A.B.C.13:443 is dest-NATed to the internal host 172.19.128.152:443 - not only on the CLI, but because the OutlookWebAccess-Interface gets served and displayed in my browser.
router#show ip nat translations | i 206 tcp A.B.C.13:443 172.19.128.152:443 37.247.X.206:26064 37.247.X.206:26064
If i disconnect the host 172.19.128.152 - than the connection wont work - OutlookWebAccess wont show up.
Also it's clear that this flow is going through this very system, because when I delete the ACE for A.B.C.13:443 it also leads to the service not beeing served.
Session 6443D284 (37.247.X.206:26694)=>(172.19.128.152:443) tcp SIS_OPEN
10-10-2018 08:23 AM
I'don't understand the setup
1) your client is on the outside?
2) and the .152 is a server on the inside?
3) and you talk about OutlookWebAccess?
-> what function has this host, is this host configured as your proxy server? or your mailserver?
10-10-2018 08:29 AM
1. Yes, I use a host on the public internet (37.247.X.206) to test availability of public reachable address A.B.C.13:443.
2. Yes. 172.19.128.152 is a host on the inside, behind A.B.C.13 (Microsoft Exchange Server - also serving Outlook Web Access at port 443/TCP).
3. see above
10-11-2018 12:22 AM
"172.19.128.152 is a host on the inside, behind A.B.C.13 "
sou you MUST have some mapping from outside comming in.?
The nat statements you published are not all nat rules?
"ip nat inside source static tcp 172.23.10.151 25 A.B.C.13 25 extendable
this is for SMTP traffic -> also mail related. Is it a second address on the same server?
10-12-2018 05:31 AM
Hello Pieter,
it turned out this was something like a "phantom element" in the config. The NAT rules i posted were the only rules defined. After a reboot of the firewall, the translation isn't working anymore. So actual behaviour of the system and running-config are aligned now.
Thanks for your feedback!
10-12-2018 05:39 AM
thank you for reporting change of status,
regards,
Pieter
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