My ASA NAT issues

[icecream-guy]

Back story: web server email spam service was upgraded, it used to ip 10.4.222.15 on port 10010, the upgrade fixed all that, the new sever was brought online at 10.4.222.18 port 443.,   now there are about 100 customers that have firewalls, which getting them to change the firewall rules is difficult at best. so NAT was implemented as a fix, the customers hit (we now call it a VIP) 10.4.222.15 port 10010 and NAT does it's thing to redirect to 10.4.222.18 port 443. (Don't ask why the traffic comes into the inside interface of the firewall to the DMZ, it's trusted   )

this all worked on an old 8.0(4)28 PIX like so:
static (spam_dmz,spam-inside) tcp 10.4.222.15 10010 10.4.222.18 https netmask 255.255.255.255

can't seem to get it to work correctly on ASA 9.1.5.19 have tried many variations

like so
object network obj-10.4.222.15
nat (SPAM-INSIDE,SPAM-DMZ) static 10.4.222.18 service tcp 10010 https

and

object network obj-10.4.222.18
nat (SPAM-DMZ,SPAM-INSIDE) static 10.4.222.15 service tcp 10010 https

and

object network obj-10.4.222.18
nat (SPAM-INSIDE,SPAM-DMZ) static 10.4.222.15 service tcp 10010 https

the latest attempt from the other thread

object network SPAM-SERVER-REAL-IP
host 10.4.222.18

object network SPAM-SERVER-OUTSIDE-IP
host 10.4.222.15

object service PORT-10010-SRC-REMAP
service tcp source eq 10010

object service PORT-443-DEST
service tcp source eq 443

nat (SPAM-INSIDE,SPAM-DMZ) source dynamic SPAM-SERVER-OUTSIDE-IP SPAM-SERVER-REAL-IP service PORT-10010-SRC-REMAP PORT-443-DEST


I'm seeing SYN timeouts' when I try to telnet through the firewall to the VIP
%ASA-6-302014: Teardown TCP connection 29 for SPAM-DMZ:10.4.222.15/10010 to SPAM-INSIDE:MY.PUBLIC.IP.ADDRESS/54591 duration 0:00:30 bytes 0 SYN Timeout

SPAM# show nat
Manual NAT Policies (Section 1)
1 (SPAM-INSIDE) to (SPAM-DMZ) source dynamic SPAM-SERVER-OUTSIDE-IP SPAM-SERVER-REAL-IP   service PORT-10010-SRC-REMAP PORT-443-DEST
    translate_hits = 0, untranslate_hits = 0


any ideas?

[icecream-guy]

seems I would need to figure 10.4.222.15 as an Outside global address?

[Dieselboy]

Hi mate what security levels are on those two interfaces? Which is higher?
If spam-inside is 100 and spam-dmz is < 100:

nat (SPAM-INSIDE,SPAM-DMZ) source dynamic SPAM-SERVER-REAL-IP SPAM-SERVER-OUTSIDE-IP service PORT-10010-SRC-REMAP PORT-443-DEST
And then the ACL rule should allow traffic to the new IP of the server, and the real port the server listens on <- this bit seems backwards to me! I think it's more logical to allow the real, untouched destination IP and port (coming from the source that is initiating the connection / requesting the connection) but NAT rules aren't thought of that way

If the above doesn't work, are you doing anything fancy with routing on the ASA? We used to route public IPs to our ASAs which had private inside and outside addressed interfaces. To make it work we needed to route the public routable IP towards the LAN. I'm not sure if this is still needed but as we have an extra block of IPs routed to us, I am still using this config as it worked first time

[deanwebb]

seems I would need to figure 10.4.222.15 as an Outside global address?

If it's truly coming in from the Outside interface, I believe so, yes.

[ski]

You could check your NAT rules order, when you have a lot of NAT in place, sometimes the ASA routes the packets to a wrong interface.

Recheck the order....

[GeorgeS]

what the packet tracer says? seems your code is correct, i would check once if there is no NAT above and second your ACL as is different the way you implement a NAT ACL after 9.x

[wintermute000]

all hail the gospel of packet tracer *snark on* the one and only redeeming feature of the ASA *snark off*.

[icecream-guy]

here is what worked

object network SPAM-SERVER-REAL-IP
host 10.4.222.18
object network SPAM-SERVER-OUTSIDE-IP
host 10.4.222.15
object service PORT-10010-SRC-REMAP
service tcp destination eq 10010
object service PORT-443-DEST
service tcp destination eq https

nat (SPAM-INSIDE,SPAM-DMZ) source static any any destination static SPAM-SERVER-OUTSIDE-IP SPAM-SERVER-REAL-IP service PORT-10010-SRC-REMAP PORT-443-DEST


Pretty close, a bit up a mixup on the port objects. Identifying the source in a NAT is new to me

[Nerm]

After reading the OP I was all giddy (yay I was gonna finally get to answer a question on here and feel like I was giving back to the community), but nope I read on and you had already figured it out. 

all hail the gospel of packet tracer *snark on* the one and only redeeming feature of the ASA *snark off*.

BUT it is one hell of a feature to have.

[deanwebb]

all hail the gospel of packet tracer *snark on* the one and only redeeming feature of the ASA *snark off*.

BUT it is one hell of a feature to have.

I also enjoy the live traffic monitoring feature. It's nice to watch for packets going to those ports the vendor forgot to mention and then permit them.

[Dieselboy]

I also enjoy the live traffic monitoring feature. It's nice to watch for packets going to those ports the vendor forgot to mention and then permit them.

My syslog is open lots. type a source or destination IP in the filter and see those connections come in or not. If you're setting something up for the first time that syslog is invaluable.

I was at a customer site in London setting up the network for the new office. At the same time they were getting their phone system installed which had remote phones for their home workers. I can't remember if it was Mitel or Avaya but their documentation wasn't very clear. I configured it all and got the guy to test it to make sure it was working. It wasn't working. I loaded up the syslog, got him to test again and found traffic on the inside trying to hit the outside NAT of the PBX which it couldn't get to. Done a reverse NAT rule and jobs a goodun.
Plenty of situations like that. Like I said - invaluable. Having that issue when your firewall is some other model or manufacturer and that could be a bit difficult to trace. You would need to do packet captures at strategic places and at least have a decent idea what you were looking for.

I also found an error in Cisco's documentation for their Expressway series the same way.