firewall/nat issues

[Pantlegz]

for whatever reason I'm having some issues with my 5510 and its NAT rules, I think. Without editing out TONS of config I'll give you guys the basic issue and I'll see if we can figure anything out if not I'll butcher my config and post it up.

Basically whay we've got is a server 10.165.x.x that's being Nat'd to a 129.130.x.x but when we try to get to the 129.130.x.x address from the inside it's not working. Don't ask me why we're doing it this way, it's the software that's being run on the server. From the outside it's no problem but inside it fails. when I use packet trace on the firewall to see where the issue is, it says the PAT is dropping the packet.

the config looks something like

globale (outside) 1 interface
static (inside,oustide) 129.130.x.x, 10.165.x.x netmask 255.255.255.255

I've also tested it with

static (outside,inside) 10.165.x.x 129.130.x.x netmask 255.255.255.255

with no luck.

 

[bobdole369]

Yes. This is working as expected.

inside

10.165.0.0/16

router(nat)

129.130.0.0/16

Outside



When a packet from outside comes in through the NAT router - it has a rule that its translated. The packets come in, and are allowed back out (acks).

Now if you have a packet coming from inside, it gets to the wrong side of the router. Even if the router knows enough to allow that translation to happen your acks are going to go out the router anyways, and off to oblivion.

Add the inside network to the routing table. 10.165.0.0/16 10.165.0.0/32 (router inside interface) netmask 255.255.255.255

 

[drebo]

What you're trying to do is effectively "green-to-green" traffic. You're trying to access a machine on a protected interface from a machine on that protected interface through the ASA. It's not configured to allow that type of connection by default.

You need the same-security-traffic command: http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080734db7.shtml

 

[Pantlegz]

What you're trying to do is effectively "green-to-green" traffic. You're trying to access a machine on a protected interface from a machine on that protected interface through the ASA. It's not configured to allow that type of connection by default.

You need the same-security-traffic command: http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080734db7.shtml

Thats sort of what I'm looking at however the IP that it's hitting is OUTSIDE and I have an ACL setup to allow this traffic in and out that's not the issue at this point. It's speciffically getting caught up when it tries to NAT, according to packet trace. I did however attempt this to see if it would resolve the issue and it does not.

What we're trying to do is NAT the 129.130.x.x address to the 10.165.x.x address on the inside interface, so anything on the inside trying to get to that address to the correct address.

Using the internal IP address, manually changing the link the program gives works the issue is end users aren't going to be happy with that as a fix for this.

@bobdole, it's not a routing issue, the whole 10.165.x.x range is routed to the inside interface.

 

[Pantlegz]

This is what's happening. I don't know why it's hitting that NAT when I have a static nat setup for it.

 

[drebo]

I've never known this to work well, and (in fact) have never attempted to implement it. It's a feature of the ASA, but I don't know if it can be disabled or not (if same-security-traffic didn't resolve it.) Did you try both intra-interface and inter-interface? You should need intra-interface, I believe.

 

[Pantlegz]

I've never known this to work well, and (in fact) have never attempted to implement it. It's a feature of the ASA, but I don't know if it can be disabled or not (if same-security-traffic didn't resolve it.) Did you try both intra-interface and inter-interface? You should need intra-interface, I believe.

I tried both and failed. I think I may end up putting it in the DMZ which would resolve all the issues but it's kind of a pain because it's a virtual machine and none of them have access to the DMZ. I wasn't sure if there was an easy fix or not.

 

[Qrilock]

You need to nat inside to inside for this to work. Here are the parts you need to make this work, assuming you don't have an ACL blocking the traffic.

same-security-traffic permit intra-interface
global (outside) 1 interface
global (inside) 1 interface
static (inside,oustide) 129.130.x.x, 10.165.x.x netmask 255.255.255.255
static (inside,inside) 129.130.x.x, 10.165.x.x netmask 255.255.255.255

 

[Pantlegz]

You need to nat inside to inside for this to work. Here are the parts you need to make this work, assuming you don't have an ACL blocking the traffic.

same-security-traffic permit intra-interface
global (outside) 1 interface
global (inside) 1 interface
static (inside,oustide) 129.130.x.x, 10.165.x.x netmask 255.255.255.255
static (inside,inside) 129.130.x.x, 10.165.x.x netmask 255.255.255.255

That helped, now it's got a different error. It's the same as before, saying that the NAT rule dropped the packet but it a different NAT rule and it's passing the first NAT. Now it's getting caught up when it tries to NAT 129.130.x.x for whatever reason it's dropping the packet there.

Basically it's getting NAT'd correctly leaving the network but we're having issues NATing getting back in the network, I think.

 

[Qrilock]

Can you post all of your nat config, including your nat 0 acl?

 

[Pantlegz]

access-list inside_nat0_outbound extended permit ip any host 129.130.1xx.xx
access-list inside_nat0_outbound extended permit ip any Support 255.255.248.0
access-list inside_nat0_outbound extended permit ip any Web 255.255.248.0
access-list inside_nat0_outbound extended permit ip any 10.165.x.xxx 255.255.252.0
access-list inside_nat0_outbound extended permit ip any 10.165.3x.xx 255.255.255.240
access-list inside_authentication extended permit tcp any any
access-list inside_nat0_outbound_1 extended permit ip any Support 255.255.255.128
access-list inside_nat0_outbound_1 extended permit ip 10.165.xx.0 255.255.0.0 10.165.5.0 255.255.255.0
access-list inside_nat0_outbound_1 extended permit ip any 10.165.xx.0 255.255.255.252
global (outside) 1 interface
global (inside) 1 interface
nat (outside) 1 10.165.xxx.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound_1
nat (inside) 1 0.0.0.0 0.0.0.0
static (outside,inside) Openrange 129.130.149.56 netmask 255.255.255.255
static (inside,outside) 129.130.149.56 Openrange netmask 255.255.255.255

I butchered it pretty bad but there's the basic setup.

 

[Qrilock]

you missed the inside,inside static translation. you shouldn't need the outside,inside translation give when I have understood.

static (inside,inside) 129.130.149.56 Openrange netmask 255.255.255.255
You also need to remove the first line of your NAT0 access list to allow the NAT to work.
access-list inside_nat0_outbound extended permit ip any host 129.130.1xx.xx

This will tell the ASA to respond to 129.130.149.56 on the inside interface and forward it back out the inside interface to the internal address of the destination server. The source IP address will be NAT'd to the inside address of the ASA forcing the destination server to send the response back to the ASA. The ASA will find an existing translation and handle it just like it would any other.
If you leave the nat0 ACE the destination server will get the original source IP and respond directly to it. The original source host will not know what to do with a response from a 10.165.x.x address when it sent the message to a 129.130.x.x.

The first few times you try to get this to work are a nightmare. Most Firewalls I have worked with in the past do this automatically, but Cisco has taken the approach that you need to be able to completely control the way traffic is NAT'd, so you must tell the ASA exactly what to do.

I hope this gets it working for you. I have now used up my allotted post count for the next 6 months.

 

[Pantlegz]

you missed the inside,inside static translation. you shouldn't need the outside,inside translation give when I have understood.

static (inside,inside) 129.130.149.56 Openrange netmask 255.255.255.255

I hope this gets it working for you. I have now used up my allotted post count for the next 6 months.

Awesome! That line fixed it. Thanks so much, it's working now. Sorry about using up all your posts but I really appreciate the help :thumbsup:

 

[Qrilock]

Glad to help.
...now back to lurker mode....

 

[Pheran]

While I'm glad you've "solved" your problem, trying to do something like this is usually an indicator of just plain bad design. Whatever you are setting up here is likely to cause you nothing but headaches down the road. Usually issues like this are addressed by split-horizon DNS. I'd spend some time rethinking this setup if at all possible.

 

[Pantlegz]

While I'm glad you've "solved" your problem, trying to do something like this is usually an indicator of just plain bad design. Whatever you are setting up here is likely to cause you nothing but headaches down the road. Usually issues like this are addressed by split-horizon DNS. I'd spend some time rethinking this setup if at all possible.

I agree the design isn't the greatest design and I should have the machine in the DMZ but there are issues there with switch space and getting stuff ordered. I will, when I'm able to get the DMZ setup correctly and have all of our servers that need access from the outside placed there to prevent these issues. I'll also look into split-horizon DNS. I took this position over and have made several major overhauls and it's a long, slow process with the government unfortunately. It's getting there tho, Thanks for the advice.