Showing results for 
Search instead for 
Did you mean: 


Zone Based Firewall and user defined IP Port Maps


This is driving us nuts. I have configured a Zone Based Firewall policy on an 800 series router but its not behaving as we expected.

For traffic coming in from the outside to the inside i have a class-map that matches an ACL and a match protocol.

The match protocol states match protocol http. I have a user defined entry for HTTP - ip port-map http port 7777.

So, if i telnet in on 7777, the packet passes the outside in ACL, then its NAT'd then it hits the ZBW but the packet is permitted. I would of thought the packet would be dropped as Telnet 7777 is not an HTTP request on TCP 777. If i change the ip port-map http

port 7777 to ip port-map ftp port 7777 and try again - telnet in on 7777 the packet is dropped as i would of expected with the following message

Sep 15 08:11:27.849: %FW-6-DROP_PKT: Dropping ftp session x.x.x.x:58923 x.x.x.x:7777 on zone-pair Extern-Intern class class-default due to policy match failure with ip ident 16073 tcpflags 0x7002 383992111 ack 0

Has anyone got any ideas why the inspect doesn't work correctly with the user defined HTTP port map?

I've been reading lots of documentation but not found the answer yet.




Accepted Solutions

So your class-map is match-all. once you telnet on port 7777 you need to send a "get" request and then see if the inspection drops it as expected.


View solution in original post

Kureli Sankar
Cisco Employee

Hmm...this is policy-match failure. It is falling under the class-default and getting dropped.

That class-map that you say is this match-any or match-all? With ZBF you dont' apply an ACL "IN" on the outside interface.

You can issue "sh policy-map type inspect zone-pair sessions

and see if the flow matched the class-map that you configured.


Thanks Kusanker for you reply.

I think we're on a different lines here.

I want my ZBF policy to match an ACL (which is fine by the way) and inspect HTTP on port 7777. Anything else should be dropped if it’s not HTTP:7777 traffic coming from the IPs listed in the ACL. With this config applied i can telnet through on port 7777 successfully but i would of expected this to fail due to the inspect HTTP:7777. I want the ZBF policy to look at the traffic coming into on port 7777 and to ensure this is HTTP traffic and not anything else, ie snmp, telnet ssh on port 7777. Does that make sense? J

Regarding the ACLs on the outside interface. I know what you are saying but I thought I would drop any packets at the edge that i'm not interested in before they start moving through the router phases - check input rate limits, policy routing, nat etc... I dont think this has any impact on this problem.



So your class-map is match-all. once you telnet on port 7777 you need to send a "get" request and then see if the inspection drops it as expected.


View solution in original post

Ok cool, not sure how we can send a get request via telnet but thanks for clarifying this. I just assumed the ZBF would drop the initial packet with it being telnet and not HTTP.


In fact i've just checked. If we remove the ip port-map http 7777 and we telnet the packet is dropped which is expected behaviour.

This is my policy-map. The class class-default drops the packet and the counter increases

policy-map type inspect Extern-Intern
class type inspect ExternIntern
class class-default

Still not sure why when the the user defined port map http:7777 exists the telnet on 7777 is permitted.


The reason why you are able to telnet on port 7777 though you have specified it as match ACL and match protcol http is as below.

1) When you do a telnet on tcp/7777, all that happens is the 3-way handshake for the TCP connection. Now, based on this exchange, the router can not decide if this a TELNET connection or a HTTP connection becasue even for a HTTP connection on tcp 7777, the first three packets are going to be the same (SYN, SYN-ACK and ACK).

2) Now, the reason why FTP on 7777 was dropped due to the fact that though even in this case the initial 3 packets are going to be a SYN,SYN-ACK and ACK like for any other TCP connection, the packets following that from the client that are going to be specific to FTP. So, when the router sees such packets, that is, non HTTP packets on port 7777, it drops it as per the configuration.

You can confirm the above facts by running wireshark on the client from where you are trying the TELNET and FTP.

I hope i was clear enough. Let me know if this helps!!



Hi Prapanch, yeah what you are saying makes sense. Cheers for the clear explanation

So i've changed the order round as follows (to match HTTP first)

class-map type inspect match-all ExternIntern
match protocol http
match access-group name Extern2Intern

But i can still get through via a telnet request on port 7777. Its confusing me.

Is it worth adding the ports to the access-group ACL? I read a Cisco document and it did say, if you match-all then the ACL should just be IP based and then you permit ports with match protocol

To use services on non-standard ports you need to implement something
called PAM. PAM can associate common services like ftp and http to ports
that are non-standard. You have done that for http

     ip port-map http port 7777

Now, any traffic that the router receives on port 7777 it will assume it is http traffic.

You are matching the acl (for source IP may be) and http and if both are true then you
have enabled inspection.

When you telnet on port 7777 it will be allowed. Why do you think it should not be?
Once you telnet if you send a non rfc compliant GET reqest then inspection may kick in
and drop it due to rfc non-compliant.



Well ideally the order in which you specify will not make any difference. The reason why it is permitted is still the same as i mentioned above. Even if yoiu use a port based ACL (mentioning tcp and destination port as tcp 7777), the behavior is still going ot same as based on he 3-way handshake alone, the router will not be able to distinguis between an HTTP connection or a TELNET connection. I am afraid there is no way you can block this telnet on port 7777, at least that i can think of.



Cheers for all your comments guys, very helpful!

Content for Community-Ad