Inside host's process using inside IP as its "public" address

[JMCraig]

Hi Folks,

I've got what should be a simple problem:

A process that wants to listen on a given port works fine until it tells the client what port to continue the interaction on. It then tells the client process to continue the conversation on the inside IP address (192.168.1.148 rather than the corresponding outside address: 209.x.y.148). This is, shall we say, down-right ineffective, since the client is coming in via the Internet and needs to use the corresponding outside address (209.x.y.148).

The problem is some combination of the PIX and the host's own routing setup. If I try to force the process via its config file to use the outside IP address, it tries to test the socket when it creates the listener object and it can't get to its own outside address so the listener object won't create (the attempt to bind to the 209.x.y.148 address fails, apparently because it's an inaccessible address).

I realize PING isn't the best test since the listener is using TCP, not ICMP, but just as an illustration, I can't PING the outside address from the host box itself--the host box apparently can't communicate with itself via its own outside address.

So, what do I need to change in my PIX settings to allow this? I don't want any public IP address to be able to communicate with this outside address & port (just the subnets ID'd in the ACL). So what source IP do I use in setting up the ACL entry? Or is this a routing problem on the box itself?

All suggestions gratefully entertained!

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com

 

[chicocouk]

You cannot create an acl to run on the pix that will allow the host on the inside network to connect to iteself using the natted address for it specified in the pix. Which is what I understand you're trying to do. To clarify what i think you want to do ...

host inside is on 10.0.0.1
this nats out as 209.x.y.148 when it goes out through the pix

You want to allow 10.0.0.1 to connect to 209.x.y.148 on a specified port. You want the pix to allow this traffic, and route the connection back to the 10.0.0.1 box.

This is not possible. Sorry.

If i've misunderstood what you're trying to do, please say.

CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[JMCraig]

Nope, it sounds like you've understood exactly what I wanted to do. (Which, naturally, may not be what needed to be done to make the %$#@! thing work....) Hmmm. So, can you do that from any machine inside (communicate with another inside box via the outside NAT'd IP address)? If not, I guess I chuck the PIX and go with a software firewall....

Huh. This shouldn't be that hard, it doesn't seem like. But, on the other hand, I can see that this wouldn't be a problem that would show up frequently (the typical situation is that the client box would be an inside address also so they'd communicate directly on the LAN address).

Thanks for the info.

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com

 

[chicocouk]

The problem you've got is down to a fundamental design decision on the PIX. Basically PIX won't reroute traffic back out the same interface it arrived on. It won't route traffic back out the same interface the way an IOS router (for example) would.

This was partly because Cisco deemed it to be a security vulnerability (supposedly to guard against hosts trying to spoof traffic), and partly because they claimed there was no valid reason for a security appliance to perform this kind of routing (except, of course, that this then breaks the pix's potential to be the hub in a hub-spoke style vpn). And partly because the pix is not intended to be sold as a router, because cisco sell other devices that can run a firewall feature set, and be a vpn endpoint, and they want people to also buy those

If it's a windows box, how about trying the following as a workaround? I'm not sure if it will work or not, but i'd at least try ...

Install the microsoft loopback adapter, and configure it with your public address of 209.x.y.148, with as small a network mask as you can get away with, and no gateway. This may be enough to fool your application into believing the port is accessible (it'll route the traffic to itself internally), and then reply to your outside hosts with the relevant port data etc.

Something like ethereal will let you capture the network traffic on the host itself, so you can see if what you think is happening actually is -

http://www.ethereal.com

CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[JMCraig]

Chicocouk,

That's a brilliant idea! I think it might work for some apps, but it didn't for this one. I'm not sure why the application's unhappy with it, but the App Server won't load the service--so, clerly I needed more than just to have a valid IP address.

I've used ethereal a fair bit (that's how I figured out what was happening on the client side) but in this case, it didn't seem necessary, the Windows Status display for the loopback adapter showed 51 packets sent; none received. The sockets won't initialize (the log file has pages and pages of Java exception traces); so I guess I've hit the end of this rope.

I'm still interested in this an an intellectual problem, but for the clients I'm going to go with a software firewall (which I know works--putting in the PIX is what gummed up the works...).

Thanks!

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com