NATing issue.

[rickcorriveau]

I originally posted this under security management but I'm thinking that might not be the correct place.  That said I am reporting this here as this appears to be a more appropriate location.

---------------------------------------

ASDM Version 649-103

ASA Version 8.2(5)33

----------------------------------------

I have an issue that I know is simple enough that has to do with NATting.  I have pasted below the config that is pertinent to this question.

We have two public IPs from our ISP, one is assigned to the Outside interface while the second one we want to be forwarded (port 5721) to an internal server.

If I point the default gateway to this firewall everything works great with the config listed below.  I however want to point the server to our core as we have several internal networks that need to access this server.

Every time I attempt to do this though it fails miserably.  I can no longer ping the external IP of .147.

I almost think that my NAT is simply configured wrong and the only reason it works when the server is pointing directly to the firewall is because it's using the default PAT configured and not the Static NAT I created.

One other thing,

When I attempt to create an access group  Inside_access_in in interface Inside all my tunnels fail because the implicit rule to permit all traffic to less secure networks is replaced.....

At this point I am just grasping at straws here....

!

interface Ethernet0/0

nameif Outside

security-level 0

ip address 64.xxx.xxx.146 255.255.255.240

!

object-group service DM_INLINE_SERVICE_1

service-object icmp

service-object icmp echo-reply

service-object icmp echo

object-group service Kaseya_External_Management tcp-udp

description Kaseya_External_Management Port 5721

port-object eq 5721

object-group service DM_INLINE_SERVICE_2

service-object icmp

service-object icmp echo-reply

service-object icmp echo

object-group service DM_INLINE_SERVICE_3

service-object icmp

service-object icmp echo

service-object icmp echo-reply

global (Outside) 1 interface

nat (Inside) 0 access-list Inside_nat0_outbound

nat (Inside) 1 0.0.0.0 0.0.0.0

static (Inside,Outside) 64.xxx.xxx.147 10.xxx.xxx.231 netmask 255.255.255.255

access-group Outside_access_in in interface Outside

route Outside 0.0.0.0 0.0.0.0 64.xxx.xxx.145 1

object-group service DM_INLINE_SERVICE_1
service-object icmp
service-object icmp echo-reply
service-object icmp echo
object-group service Kaseya_External_Management tcp-udp
description Kaseya_External_Management Port 5721
port-object eq 5721
object-group service DM_INLINE_SERVICE_2
service-object icmp
service-object icmp echo-reply
service-object icmp echo
object-group service DM_INLINE_SERVICE_3
service-object icmp
service-object icmp echo
service-object icmp echo-reply

!

global (Outside) 1 interface
nat (Inside) 0 access-list Inside_nat0_outbound
nat (Inside) 1 0.0.0.0 0.0.0.0
static (Inside,Outside) 64.xxx.xxx.147 10.xxx.xxx.231 netmask 255.255.255.255
access-group Outside_access_in in interface Outside
route Outside 0.0.0.0 0.0.0.0 64.xxx.xxx.145 1

!

Thank you in advance !!

[Marius Gunnerud]

We have two public IPs from our ISP, one is assigned to the Outside  interface while the second one we want to be forwarded (port 5721) to an  internal server.

So you want to access the server using port 5721 on the outside?  what port do you want to translate it to on the inside?  This could be a routing issue in the core of the network.  Could you post a network diagram of how you would like the server to be connected to the network?

When I attempt to create an access group  Inside_access_in in interface  Inside all my tunnels fail because the implicit rule to permit all  traffic to less secure networks is replaced.....

You would need to post the ACL configuration as well as what the source and destination subnets are for the VPN tunnel for us to help further here.

--
Please remember to rate and select a correct answer

[rickcorriveau]

So you want to access the server using port 5721 on the outside? 

Yes, I am looking to allow our off-campus computers with this Kaseya agent running on port 5721 access to our internal server.

------------------------------------------------------------------------

What port do you want to translate it to on the inside? 

Port 5721 as this is the port the server is expecting this traffic to use.

------------------------------------------------------------------------

This could be a routing issue in the core of the network.

This is possible, though I do have a route in my core to forward 64.xxx.xxx.147 out the firewalls inside interface. I do know this might not be the best/ correct way to do this though as the external IP 64.xxx.xxx.147 is nated to 10.5.7.231 (real IP of the Kaseya server). I have to say I am very lost here…As I’m sure you can tell at this point.

------------------------------------------------------------------------

Could you post a network diagram of how you would like the server to be connected to the network?

I have attached a network diagram which I hope is clearer than I have been so far. Sorry…

--------------------------------------------------------------------------

You would need to post the ACL configuration as well as what the source and destination subnets are for the VPN tunnel for us to help further here.

The ACL was just something I was grasping at straws for. I have pulled all this out. The only thing I have related to this now is just the NAT statement

global (Outside) 1 interface

nat (Inside) 0 access-list Inside_nat0_outbound

nat (Inside) 1 0.0.0.0 0.0.0.0

static (Inside,Outside) 64.xxx.xxx.147 10.5.7.231 netmask 255.255.255.255

access-group Outside_access_in in interface Outside

----------------------------------------------------------------------------

[Jon Marshall]

Rick

This is possible, though I do have a route in my core to forward 64.xxx.xxx.147 out the firewalls inside interface.

The route would not be for the 64.x.x.x address though.  The return traffic from the internal server would have destination IPs of the clients on the internet.

So you would need a default route from the core pointing to the inside interface to the ASA to account for all the possible internet IPs.

That or if you don't want a default route to the firewall you would need to NAT all  the source internet IPs as they pass through the firewall to the server.

Usually though a default route is used and you may have this already so routing might not be an issue.

The configuration you have posted is referencing acls ie. one for NAT on the inside interface and one applied to the outside interface but you haven''t actually posted the acls themselves.

You static NAT statement for the server looks fine other than it is doing NAT for all ports as opposed to just the specific port you mention. This is not necessarily an issue and wouldn't stop it working. Presumably your outside acl is only allowing traffic to that public IP on the specific port.

Jon

[Marius Gunnerud]

As Jon has mentioned make sure that you have a default route in your core network pointing to the ASA inside interface.

As for NATing port 5721 to the Kaseya server the command would look something like this (given that it is the outside interface IP that is being translated:

static (inside,outside) tcp interface 5721 10.5.7.231 5721

Would help to see the ACL configuration if you still have problems.

And if you require help with the VPN tunnels, we would need to see the crypto configuration as well as all related ACLs and NAT0

--
Please remember to rate and select a correct answer

[rickcorriveau]

Jon Marshall

The route would not be for the 64.x.x.x address though. The return traffic from the internal server would have destination IPs of the clients on the internet.

That is what gets sticky here. This is just one of many T1 circuits we have in our enterprise. Our core has a default route out to our main internet circuit which is not this firewall in question.

So you would need a default route from the core pointing to the inside interface to the ASA to account for all the possible internet IPs.

That or if you don't want a default route to the firewall you would need to NAT all the source internet IPs as they pass through the firewall to the server.

Yes, I’m thinking this would be my only possible option other than setting the servers default gateway to the inside interface of this firewall.

Usually though a default route is used and you may have this already so routing might not be an issue.

The configuration you have posted is referencing acls ie. one for NAT on the inside interface and one applied to the outside interface but you haven't actually posted the acls themselves.

Sorry, I must have missed this while trying to filter the config.

access-list Outside_access_in remark Kaseya Port 5721 Inbound Access

access-list Outside_access_in extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management

access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_3 any host 64.xxx.xxx.147

access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_1 any any 

You static NAT statement for the server looks fine other than it is doing NAT for all ports as opposed to just the specific port you mention. This is not necessarily an issue and wouldn't stop it working. Presumably your outside acl is only allowing traffic to that public IP on the specific port.

I don’t know how to setup a NAT to a specific port using the ASDM, I thought that an ACL would need to be added after the NAT was created to limit the port(s).

----------------------------------------------------------------------------------------------------------------------------------------------------------

Marius Gunnerud

As Jon has mentioned make sure that you have a default route in your core network pointing to the ASA inside interface.

I cannot do this. Our default route points to our main internet circuit for the enterprise. The firewall in question is just a T1 with a few VPNs on it. Since the VPNs do use a lot of bandwidth we wanted to use this same firewall for our external Kaseya clients to communicate to the Kaseya server inside our network on port 5721

As for NATing port 5721 to the Kaseya server the command would look something like this (given that it is the outside interface IP that is being translated:

static (inside,outside) tcp interface 5721 10.5.7.231 5721

Would help to see the ACL configuration if you still have problems.

I have done so many things at this point trying to get this to work I have completely confused myself. The command you listed above. Is this to replace the current static (Inside,Outside) 64.140.235.147 10.5.7.231 netmask 255.255.255.255 I have or along side?

The external block I have for this T1 circuit is .146 /240. Will this mean the firewall will see the traffic being sent to .147 without the need for the .147 NAT or will it just forward ALL traffic coming into the firewall on port 5721 to 10.5.7.231?

And if you require help with the VPN tunnels, we would need to see the crypto configuration as well as all related ACLs and NAT0

Amazingly enough the VPNs are not an issue and are functioning correctly.  Though while fighting with this I have had to reload the firewall a few times without saving the config as I had completely hosed it...

[rickcorriveau]

Not sure why this didn't show properly in my last reply.  Let's see if this works better.

access-list Outside_access_in remark Kaseya Port 5721 Inbound Access

access-list Outside_access_in extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management

access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_3 any host 64.xxx.xxx.147

access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_1 any any

[Jon Marshall]

Rick

That default route is probably the issue then. Try this -

access-list PNAT permit ip any host 64.x.x.x

nat (outside) access-list PNAT outside   <--- note the keyword outside at the end as well as in the interface part.

global (inside)   interface

what this this does is NAT all client internet IPs to the inside interface IP of the ASA as they pass from outside to inside. You can if you want use a different IP ie. not the interface IP. You need to make sure either way that the core has a route back to the IP used. If it is the interface IP it probably will but if you use a different IP from an unused subnet you need to add a route on the core for that IP pointing to the ASA inside interface.

Note -

1) the acl permits all IP, you may want to restrict it to just the specifc server ports

2) make sure you use a nat-id that is not in use

3) i have used this before successfully but i have also seen it break other NAT connections so you need to test out of hours.  Sorry i can't be more specific but it was quite a while ago

Jon

[rickcorriveau]

That default route is probably the issue then. Try this -

access-list PNAT permit ip any host 64.x.x.x

Will this cause issues on the firewall with any preexisting VPNs or other systems using this firewall to access the internet (only a few if any).

nat (outside) access-list PNAT outside   <--- note the keyword outside at the end as well as in the interface part.

global (inside) interface

The NAT IDs, is this just an arbitrary number or does this need to be specific ID relating to an already existing ID?

This is what I have currently....

global (Outside) 1 interface

nat (Inside) 0 access-list Inside_nat0_outbound

nat (Inside) 1 0.0.0.0 0.0.0.0

static (Inside,Outside) 64.xxx.xxx.147 10.5.7.231 netmask 255.255.255.255

access-group Outside_access_in in interface Outside

what this this does is NAT all client internet IPs to the inside interface IP of the ASA as they pass from outside to inside. You can if you want use a different IP ie. not the interface IP. You need to make sure either way that the core has a route back to the IP used. If it is the interface IP it probably will but if you use a different IP from an unused subnet you need to add a route on the core for that IP pointing to the ASA inside interface.

So if I’m understanding this correctly I would want to change the global (inside) interface to global (inside) 64.xxx.xxx.147 ?

Note -

1) the acl permits all IP, you may want to restrict it to just the specific server ports

2) make sure you use a nat-id that is not in use

3) i have used this before successfully but i have also seen it break other NAT connections so you need to test out of hours. Sorry i can't be more specific but it was quite a while ago

Yes, the breaking part is what I’m afraid of as well. I just want any outside user who is configured to hit 64.xxx.xxx.147 to be able to connect to the internal server 10.5.7.231 and then their traffic forwarded back to them.

[Jon Marshall]

Rick

So if I’m understanding this correctly I would want to change the global (inside) interface to global (inside) 64.xxx.xxx.147 ?

No, you are getting confused between source and destination IPs. 

The static NAT you added takes care of the server. The issue you have is this -

1) client connects to the 64.x.x.147 from the internet. Your ASA translates 64.x.x.147 to the real IP of 10.5.7.231 and send the traffic to your server

2) the source IPs in 1) could be any internet address. So when your server sends the traffic back when it gets to the core switch that switch uses it's default route and sends it off to the wrong place.

So you need to modify the source IPs (because you cannot change the default route in the core) so that they are sent back to the ASA. You can change them all to the inside interface IP on the ASA or you can use another address ie. any private address you choose. It is simply used to get the traffic back to the ASA.

If you did use a different IP then it needs to be from a new subnet ie. one not already in use in your network and you would need to add a route to it on the core switch pointing to the ASA so traffic is sent back to the ASA.

The nat-id can be any number but they must match for the nat/global statements i posted. just choose a number not in use.

As for whether it will cause problems, it shouldn't do because the acl is very specfic ie. only traffic to that specific 64.x.x.147 address. But like i say i have seen it break things before although i have used it extensively also and the majority of time it has worked well.

That is why you need to try it out of hours and test it ie. not only does it work but does it affect anything else as well.

Jon

[rickcorriveau]

So I was on the right path....at one point then.  I had grabbed 192.168.27.96 /240, thinking I would somehow NAT 192.168.27.97 to 64.xxx.xxx.147.  Then add a route in my core to point traffic destined to 192.168.27.97 to the specific firewall.  I must have been putting it in backwards then?  I could not get it to work and then well.  As you can see from the thread so far.. I'm a train wreak !!

192.168.27.97 is NOT used on my network at all so this should work right?

So my final config should look something like this?

access-list PNAT permit ip any host 64.x.x.x

nat (outside) 2 access-list PNAT outside  

global (inside) 2  192.168.27.97

Of course the rest of the config would remain the same. 

I cannot begin to express my gratitude for your patience and assistance with this !!

[Jon Marshall · Accepted solution]

Rick

No problem, glad to try and help.

So your static NAT will translate 64.x.x.147 to 10.5.7.231.

And the nat/global will translate all client internet IPs to 192.168.27.97.

The only thing you haven't mentioned is you will need a route on your core switch for 192.168.27.97 pointing back to the ASA inside interface ie.

ip route 192.168.27.97 255.255.255.255

the route assumes that the core switch is directly connected (at L3) to the ASA ?

Jon

[Marius Gunnerud]

You can still use the current default route, but you will need to configure TCP bypass on the ASA, so that it will ignor the asynchronos routing.  Although this is a workaround, I do suggest adding a PBR config on the core network instead.  TCP bypass tells the ASA to ignor certain checks so that it will still accept and pass unexpected traffic.

Here is a link on how to configure TCP bypass...should you choose to do this.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/conns_tcpstatebypass.html

--
Please remember to rate and select a correct answer

[rickcorriveau]

YAY!!!  It works !!!  I added the lines you suggested and now we are running again !!!  Thank you soooooooo much !!!!

global (Inside) 2 192.168.27.97
nat (Outside) 2 access-list PNAT outside
static (Inside,Outside) 64.xxx.xxx.147 10.5.7.231 netmask 255.255.255.255

access-list PNAT remark Kaseya Remote access
access-list PNAT extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management

Route in our core pointing to .49 which is the NATTING firewall

ip route 192.168.27.97 255.255.255.255 10.5.100.49

[Jon Marshall]

Rick

No problem, glad you go it working.

Jon