DSL HTTP on Non-standard Port

Hey all,

I'm working on an issue right now we're having with one of our sites. The remote site isn't able to access http servers on non-standard ports. They need access to an http server on port 11001. The outbound access-list on the interface includes:

260 permit tcp any any eq 11001

When I attempt to establish a connection with a client on the LAN, it simply hangs until it times out.

When I perform a:

show ip inspect sessions

I can see the TCP session:

Session 84AAB31C (10.10.10.10:1470)=>(70.70.70.70:11001) tcp SIS_OPENING

It stays in this state until it times out. So the session is failing to open for some reason.

Any tips on what I might check to identify the cause?

Thanks.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

mikearama

I'd first verify that it is the access list that is causing you grief. The way to do that is to change the line to something vague, ie:

260 permit tcp any any eq http

If that doesn't work, your issue isn't your access list... it's elsewhere. If that works, you can revisit the acl and fine tune your statements. Do you have the ability to make a change like this for the time being to verify connectivity?

sprkymrk

Do you have a permit on the return traffic? Something like:

access-list 111 permit tcp any x.x.x.x x.x.x.x established

iproute

mikearama wrote:

I'd first verify that it is the access list that is causing you grief. The way to do that is to change the line to something vague, ie:

260 permit tcp any any eq http

If that doesn't work, your issue isn't your access list... it's elsewhere. If that works, you can revisit the acl and fine tune your statements. Do you have the ability to make a change like this for the time being to verify connectivity?

Thanks for the reply. Yes I can make changes for now, the site isn't in full swing at this hour. I've tried this one though as it was my first inclination. I simply removed the access list from the interface with no benefit. I'm wondering if the IOS firewall is preventing access somehow.

iproute

sprkymrk wrote:
Do you have a permit on the return traffic? Something like:
access-list 111 permit tcp any x.x.x.x x.x.x.x established

No I do not. I'll give it a shot.

Edit: Upon second glance, on the inbound ACL we have:

90 permit tcp any any established

$:\$

Netstudent

maybe try telnetting to the http server on port 11001. OR issue a Netstat -a on the http server's CMD to see if it is listening on that port.

mikearama

iproute wrote:
Edit: Upon second glance, on the inbound ACL we have:
90 permit tcp any any established

Hey, that can't work... you've got an extended acl using a standard acl number. Did that not give you an error?

Also, do you have access to your clients ACL? Can you view it for permit/deny statements? Have a contact person there?

Mike

iproute

mikearama wrote:
iproute wrote:
Edit: Upon second glance, on the inbound ACL we have:
90 permit tcp any any established
Hey, that can't work... you've got an extended acl using a standard acl number. Did that not give you an error?

Also, do you have access to your clients ACL? Can you view it for permit/deny statements? Have a contact person there?

Mike

I believe it's a function if the IOS we use on these routers. That's not actually the access-list number/name it's the line number of the statement.

For the second question I don't have access to the external vendor that owns the http server we're trying to connect to. I can get in touch with them though if all other options are exhausted. We've verified connectivity at some of our other sites though, so it would seem unlikely that they're blocking us.

dtlokee

mikearama wrote:
iproute wrote:
Edit: Upon second glance, on the inbound ACL we have:
90 permit tcp any any established
Hey, that can't work... you've got an extended acl using a standard acl number. Did that not give you an error?

Also, do you have access to your clients ACL? Can you view it for permit/deny statements? Have a contact person there?

Mike

The 90 in this case is the sequence number, not the access list number.

Does this router have ip inspection on it?

A few things to check:

1. If the router is performing NAT yuo will need a static translation rule to allow the inbound traffic.
2. There may be an inbound access-list on the inside interface blocking the return traffic. or an outbound access-list on the outside interface blocking the return traffic.
3. If you are using IP inspection, make sure the return traffic is subject to inspection to add an entry to the state table

iproute

dtlokee wrote:
mikearama wrote:
iproute wrote:
Edit: Upon second glance, on the inbound ACL we have:
90 permit tcp any any established
Hey, that can't work... you've got an extended acl using a standard acl number. Did that not give you an error?

Also, do you have access to your clients ACL? Can you view it for permit/deny statements? Have a contact person there?

Mike
The 90 in this case is the sequence number, not the access list number.

Does this router have ip inspection on it?

A few things to check:

1. If the router is performing NAT yuo will need a static translation rule to allow the inbound traffic.
2. There may be an inbound access-list on the inside interface blocking the return traffic. or an outbound access-list on the outside interface blocking the return traffic.
3. If you are using IP inspection, make sure the return traffic is subject to inspection to add an entry to the state table

Thanks for the reply.

1. My inexperience shows on this one. I don't quite understand why I'll need a static translation rule to allow the inbound traffic when I'm currently doing PAT. I'm not sure what makes this instance different from say a normal http request with regard to NAT.
2. I tried dropping all access-lists, the problem persists.
3. I tried disabling IP inspection on associated interface (Dialer1), the problem persists.

dtlokee

You need a static translation rule because the PAT rule you have created only makes an entry in the translation table when the traffic originates from the inside network going to the outside. You need a static rule to allow traffic from the outside to create an entry in the translation table.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e51.shtml

you will need an entry somthing like this:

ip nat inside source static tcp 192.168.100.100 11001 155.44.55.4 11001 extendable

replace the 192.168.100.100 with the inside server address, the 11001 with the port number you want to use, and the 155.44.55.4 with the address of the outside interface.

Netstudent

thats interesting. I noticed that little section in the INCD book where it's talking about PAT and it mentions needing a static translation for outside hosts, but i never quite grasped that fully until now. That is a simplistic, yet effective article there. I'm glad I got that last little glich clarified before 3.

iproute

dtlokee wrote:

You need a static translation rule because the PAT rule you have created only makes an entry in the translation table when the traffic originates from the inside network going to the outside. You need a static rule to allow traffic from the outside to create an entry in the translation table.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e51.shtml

you will need an entry somthing like this:

ip nat inside source static tcp 192.168.100.100 11001 155.44.55.4 11001 extendable

replace the 192.168.100.100 with the inside server address, the 11001 with the port number you want to use, and the 155.44.55.4 with the address of the outside interface.

Thanks for the help dtlokee. It's appreciated.

In this instance, the traffic should be originating from within the inside network going to the outside. The webserver my organization's site is connecting to is owned and operated by an external party on the Internet.

I see what you're saying but don't see how it applies here. I'll create a little diagram to try and help clarify.

[ My Company's Network ].............................................[ External Vendor's Network ]
[LAN]---[2611XM Router]---[DSL "Modem"]---(Internet)

[Webserver on port 11001]

In this instance, the user's on [LAN] are opening their web browser and attempting to hit that web server on that port, but it fails.

r_durant

iproute...this may be a long shot

You said you tried dropping all access-lists and disabling IP inspection on associated interface (Dialer1), but the problem persists.

I know that on some of these DSL Modems, they don't always allow all traffic or ports to pass through them, have you tried checking to see if the DSL Modem is blocking the traffic some how?

dtlokee

iproute wrote:

dtlokee wrote:

You need a static translation rule because the PAT rule you have created only makes an entry in the translation table when the traffic originates from the inside network going to the outside. You need a static rule to allow traffic from the outside to create an entry in the translation table.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e51.shtml

you will need an entry somthing like this:

ip nat inside source static tcp 192.168.100.100 11001 155.44.55.4 11001 extendable

replace the 192.168.100.100 with the inside server address, the 11001 with the port number you want to use, and the 155.44.55.4 with the address of the outside interface.

Thanks for the help dtlokee. It's appreciated.

In this instance, the traffic should be originating from within the inside network going to the outside. The webserver my organization's site is connecting to is owned and operated by an external party on the Internet.

I see what you're saying but don't see how it applies here. I'll create a little diagram to try and help clarify.

[ My Company's Network ].............................................[ External Vendor's Network ]
[LAN]---[2611XM Router]---[DSL "Modem"]---(Internet)
[Webserver on port 11001]

In this instance, the user's on [LAN] are opening their web browser and attempting to hit that web server on that port, but it fails.

I'm sorry I was reading this as you needed inbound access to the server from outside. In that case you need to update your IP inspection configuration to treat traffic on the nonstandard port for inspection.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsec_c/part15/schpam.htm

Enable your inspection rule again if you have not, then use the "ip port map http 11001" command (assuming 11001 is the port you want to inspect)

iproute

dtlokee wrote:

iproute wrote:

dtlokee wrote:

You need a static translation rule because the PAT rule you have created only makes an entry in the translation table when the traffic originates from the inside network going to the outside. You need a static rule to allow traffic from the outside to create an entry in the translation table.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e51.shtml

you will need an entry somthing like this:

ip nat inside source static tcp 192.168.100.100 11001 155.44.55.4 11001 extendable

replace the 192.168.100.100 with the inside server address, the 11001 with the port number you want to use, and the 155.44.55.4 with the address of the outside interface.

Thanks for the help dtlokee. It's appreciated.

In this instance, the traffic should be originating from within the inside network going to the outside. The webserver my organization's site is connecting to is owned and operated by an external party on the Internet.

I see what you're saying but don't see how it applies here. I'll create a little diagram to try and help clarify.

[ My Company's Network ].............................................[ External Vendor's Network ]
[LAN]---[2611XM Router]---[DSL "Modem"]---(Internet)
[Webserver on port 11001]

In this instance, the user's on [LAN] are opening their web browser and attempting to hit that web server on that port, but it fails.

I'm sorry I was reading this as you needed inbound access to the server from outside. In that case you need to update your IP inspection configuration to treat traffic on the nonstandard port for inspection.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsec_c/part15/schpam.htm

Enable your inspection rule again if you have not, then use the "ip port map http 11001" command (assuming 11001 is the port you want to inspect)

Thanks for all the help dtlokee. I apologize for not being more clear. This looks very promising and I'll give it a shot just as soon as I have the opportunity.

dtlokee

iproute wrote:

dtlokee wrote:

iproute wrote:

dtlokee wrote:

You need a static translation rule because the PAT rule you have created only makes an entry in the translation table when the traffic originates from the inside network going to the outside. You need a static rule to allow traffic from the outside to create an entry in the translation table.

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e51.shtml

you will need an entry somthing like this:

ip nat inside source static tcp 192.168.100.100 11001 155.44.55.4 11001 extendable

replace the 192.168.100.100 with the inside server address, the 11001 with the port number you want to use, and the 155.44.55.4 with the address of the outside interface.

Thanks for the help dtlokee. It's appreciated.

In this instance, the traffic should be originating from within the inside network going to the outside. The webserver my organization's site is connecting to is owned and operated by an external party on the Internet.

I see what you're saying but don't see how it applies here. I'll create a little diagram to try and help clarify.

[ My Company's Network ].............................................[ External Vendor's Network ]
[LAN]---[2611XM Router]---[DSL "Modem"]---(Internet)
[Webserver on port 11001]

In this instance, the user's on [LAN] are opening their web browser and attempting to hit that web server on that port, but it fails.

I'm sorry I was reading this as you needed inbound access to the server from outside. In that case you need to update your IP inspection configuration to treat traffic on the nonstandard port for inspection.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsec_c/part15/schpam.htm

Enable your inspection rule again if you have not, then use the "ip port map http 11001" command (assuming 11001 is the port you want to inspect)

Thanks for all the help dtlokee. I apologize for not being more clear. This looks very promising and I'll give it a shot just as soon as I have the opportunity.

Not your fault, I skim these posts sometimes and don't fully read all the details

I do the same thing on the CCIE lab, prolly not the best idea.

iproute

Well, I tried the following with no luck:

#ip port-map http port 11001 list 61

#show access-list 61
Standard IP access list 61
    10 permit IP.OF.WEB.SVR (8 matches)

#show ip port-map
Host specific:   http             port 11001  in list 61   user defined

I unsuccessfully attempted it with a less specific option as you recommended in your post with:

ip port map http 11001

I'll keep up the good fight on this issue. It's interesting at least.

Note: I have no idea why this would matter, but I figured I'd mention it anyway.

The office in question uses a DSL modem where the router does the PPPoE authentication and NAT. It seems to work w/o issues at the offices where we have a double NAT (performed by Cisco router and DSL "modem").