Fixup of HTTP

[jason.scott]

We have some clients who wish to access an internal server on http port 9000. The appropriate conduit is in place (it actually allows all IP through as this server does many things) and I have added a fixup protocol http 9000 to the PIX config. However our clients are still unable to access the web interface of the server.

In theory is that all that is required to enable http access over port 9000 to any particular box?

Does the remote site's firewall require the same fixup command or should it be enabled only on the incoming firewall?

Btw, for those who gasp at the security of the above, the 'external' network is still a private secure network rather than the internet!

[mostiguy]

fixup http is only necessary for java and activex filtering - it doesn't do much elsewise. It doesn't do anything as complex as what fixup smtp, etc does.

If you are certain that the conduits/acl allow access, then you likely:

1. need to clear xlate on the pix - have you tried that?

2. need to see if the web server is configured to only respond to certain source ip addresses.

[jason.scott]

Our server is listening on port 9000 so we needed the fixup command to allow http connections on anything other than port 80.

I've just done some more testing with an externally located PC and been unable to reach the address on port 9000. Standard http works fine.

Configured is the following:

fixup protocol http 9000

static (inside,outside) 172.24.1.1 10.1.15.135 netmask 255.255.255.255 0 0

conduit permit ip host 172.24.1.1 host 192.168.1.1

Can't understand why it wouldn't work. All ip traffic permitted. Fixup in place. Translation working ok. (Btw above addresses altered from real)

[jmia]

Hi Jason,

Here's a example (from the understanding of your post) - The static command is used first to statically translate 10.0.1.10 to 192.168.1.101, the conduit cmd in this example will permit HTTP access ONLY to host 10.0.1.10 (translated to 192.168.1.101).

So, translated on the PIX config:

>pix(config)# static (inside,outside) 192.168.1.101 10.0.1.10 netmask 255.255.255.255

>pix(config)# conduit permit tcp any eq www host 172.16.1.1

*172.16.1.1 = host on the internet.

*10.0.1.10 = inside client

Do clear xlate and save config with write memory. You might want to consider moving from conduit to ACLs.

Hope this helps - Jay

[jason.scott]

ACLs would be nice instead of conduits! Unfortunately our config is slightly large and we have to wait till time permits.

I've tried combinations of the conduit to permit just http traffic, or to permit ip traffic over port 9000. Nothing seems to work.

I can access the server on the internal network over port 9000 so everything seems ok there.

Wondering if somehow, during the translation phase, the port assignments are being altered.

[jmia]

Jason,

I think what might be going is that port 9000 is assigned to CSListner, have a look at:

http://www.iana.org/assignments/port-numbers and also

http://www.bekkoame.ne.jp/~s_ita/port/port9000-9999.html

Just thought about this port number and checked the above URL.

Let me know your thoughts - Thanks, Jay

[jason.scott]

Thanks Jay, that is an interesting lead to follow up on!

I believe (will check with server guys) that the application being accessed id running on an IBM Websphere server, which makes use of 9000 port.

Checking their newsgroups brings up lots of posts about conflicts on this port and problems encountered with it.

I'll let you know the outcome when its finally resolved.

Thanks for you help.

Regards,

[jmia · Accepted solution]

Hi Jason,

When you said (above), IBM Websphere I looked up some documents on another problem from a customer that I was helping out not so long ago, and found the following info:

http://www7b.software.ibm.com/wsdd/WASInfoCenter/wasa_content/080503.html

Maybe your server guys will find this interesting, to be honest I think you can get around this problem by assigning a different port number i.e. 8080 range.

Hope this helps and let me know how you get on and please remember to vote on this forum so that answers to forum questions can be used by other members if they have helped you as someone else might be encountering the same problem as you have.

Thanks/regards - Jay

[jason.scott]

Hi Jay,

Your responses and others have been helpful. Unfortunately it has turned out to be something other than the port assignment. We swapped to using port 8081 but still no luck.

However after some testing and analysis of the pix logs it seems that the initial connection to the server is occuring (conduit hit) but shortly there after the client is being told to access the server on an internal private ip address. AS you can imagine this fails.

As far as I can ascertain, this problem now looks to be caused by programming on the server itself. From what I've described does that sound plausible?

Thanks,

Jason

[jmia]

Hi Jason,

Mmm... Have you got any syslog message that you could post and your PIX config either here or direct to me at noc1@vodafone.net please remember to change any passwords and inside IPs. From your reply it might/might not be the server BUT need to see the syslog messages to confirm if there are anything spooky going on the PIX.

For logging do:

logging on

logging buffer debug

Try a connection, then:

sho logg

Also did you do cmd 'clear xlate' after the change of the port numbers??

Thanks - Jay

[jason.scott]

All sorted now. It turned out to be down to the port numbers after all.

Thanks!