Re: IPv6 & SMTP ZBF Issues

rbrocks · ‎01-23-2011

Hello everyone

I am having some issues with IOS 15.1.3T on a 2911. I'm by no means a Cisco expert and am trying to teach myself the ins and outs of IOS but am having some difficulties that I am hoping someone can help me out with.

The first issue I have is with the ZBF blocking IPv6 packets between interfaces if I don't have its supported v4 rules set up just so. I was under the impression that the ZBF completely ignores IPv6 traffic. To illustrate what I mean, I'll give some details as to my configuration. I have all 3 interfaces configured with different zones. Gig0/0 is my WAN interface, Gig0/1 is my LAN interface, and Gig0/2 is my DMZ interface. I have a globally routable /48 as well as a /64 via Hurricane Electric. I have separate /64 networks set up on the LAN and DMZ interfaces and would think that without IPv6 ACLs on those interfaces, IPv6 traffic would flow completely unimpeded and indeed, this is the case so long as I don't have any v4 inspect rules for certain types of traffic with restricted source and destination addresses. For instance, if I am looking to use the ZBF to only allow HTTP from an IPv4 address on my LAN to a single IPv4 DMZ host (say for instance, the DMZ host that will be running my company's public web site), and the default rule is to drop nonmatching traffic in that zone pair, once the rule is set, the ZBF will drop IPv6 HTTP traffic from the LAN to the DMZ as well, regardless of how the IPv6 ACLs on the interfaces are set. If you log the default drop action on the zone pair, it says that it matched the IPv6 packet with the default ZBF action and dropped the packet. If I were to change the source and destination to any, the ZBF will then match the IPv6 traffic to that rule and allow it to pass. Any ideas????

The second issue I have is with respect to SMTP inspection. It seems that the ZBF will reset the connection if there is anything in the email other than simple text. Even something as simple as a small picture in a signature will cause the ZBF to drop the connection. I would assume that the reason for this is that the firewall is dropping emails larger than a certain insanely small size but I don't know how or even if it is possible to change this parameter. I haven't been able to find anything on the subject in my various web searches. I've just set the firewall rule to inspect TCP since that particular host is behind NAT anyway, which would provide filtering of the host's other ports. I would like to get SMTP inspection working though as it would provide another, stronger line of defense for my mail server.

Any assistance would be much appreciated.

gpsoctate · ‎01-29-2011

I am not too sure about the IPv6 issue but I think I may be able to help you with the email traffic. Please turn on the 'ip inspect log drop-pkt' on the router and then look at debug level logs on the router. That should tell you the reason for packet drop/termination of connection.

GPS

Voipesec Network Solutions

http://www.voipesec.com

http://www.voipesec.in

rbrocks · ‎01-30-2011

So, it's dropping the packet because of an out of order segment..

%FW-6-DROP_PKT: Dropping tcp session :23658 :25 on zone-pair sdm-zp-VPNOutsideToInside-1 class sdm-nat-smtp-1 due to Out-Of-Order Segment with ip ident 0

Is not "ip virtual-reassembly in" on the inbound interface supposed to correct this condition? Also, why would it allow out of order segments with TCP inspection but not SMTP?

Also, while I'm still testing the IPv6 problem to ensure it is actually doing what I want it to, it appears that I have found a solution.

Maykol Rojas · ‎01-30-2011

Hello,

A packet coming out of the order is different that it comes fragmented. You are having problems wiith OOO packets. Normally this would be something that you would have to work with upstream routers ISP etc.

Fortunately on version 15, there is a new parameter map that you can configure for OOO packets.

Cheers

Mike

rbrocks · ‎01-30-2011

Might you be able to provide an example or some documentation for this parameter map? <-Cisco noob in training...

voipesec1 · ‎01-31-2011

I agree with Mike that fragmentation is different than OOO.

Also, you don't notice the issue with smtp inspection disabled because, when it is turned on, the router has to reassemble OOO packets before it can do the deep packet inspection at layer 7. If the packets are out of order, the limited buffer on the router to hold OOO packets may not be able to handle too many OOO packets and starts dropping them. This sometimes creates a chain reaction and the tcp session is broken.

Admin

Voipesec Network Solutions

rbrocks · ‎01-31-2011

Yes, I can see what you both are saying. I interpreted an out of order segment to be a packet that was fragmented with the individual resulting packets arriving out of order, not whole unfragmented packets arriving out of order. I suppose this would make sense with an application inspecting firewall. It also now makes sense that inspection of SMTP would cause the issue where as inspection of TCP wouldn't as inspection of TCP really only allows for standard SPI type protections as opposed to inspection for protocol compliance as you have with the inspection of more specific protocols such as SMTP, POP, IMAP, HTTP, etc. I don't really have any experience with application inspecting capable firewalls, so thinking like this is rather new to me. To this point, I have dealt with SMB hardware from Netgear and others, which don't do application inspection at all and have had very limited experience with Cisco hardware, none of which has been with the brand's security features. I must say that while the learning curve for Cisco hardware is pretty steep for those of us used to SMB hardware, I have found the platform to be very powerful (as one would expect from such an expensive product). As with everything else, you just have to learn the ins and outs of the product and exactly what you have to do to get it to do what you want. To that end, how exactly do I go about increasing the system's buffer for OOO segments? As was stated before, I would imagine that it is done in a parameter map, but being very new to Cisco hardware and not having been able to find anything on point already on the Internet, I would greatly appreciate if someone could give me an example or point me to a document that could explain how to do this.

I have also confirmed that the solution I found for the IPv6 issue is working as expected, so that problem is resolved.

voipesec1 · ‎01-31-2011

Here's what you can try:

http://www.voipesec.com/tipsntricks.html

If this does not help, track the source of OOO packets.

Admin

Voipesec Network Solutions

cadet alain · ‎02-01-2011

Hi,

I have also confirmed that the solution I found for the IPv6 issue is working as expected, so that problem is resolved.

Could you explain what you did to solve the issue as it may help others reading this forum.

Regards.

Alain.

Don't forget to rate helpful posts.

rbrocks · ‎02-04-2011

So, some updates..

First, the information available at http://www.voipesec.com/tipsntricks.html, according to http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_ooop.html is for the older CBAC firewall. I'm using the ZBF. Using the commands specified in the first URL to Google a solution with parameter-map took me to http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew.html#wp1122609, where I found "Note OoO processing is not supported in SMTP because SMTP supports masking actions that require packet modification." In addition to this, I have discovered that the issue only seems to exist for some reason when the sending server is virtualized with Hyper-V, using a Broadcom 5708 NIC to attach to the physical network. I can only assume it has something to do with either the combination of Microsoft virtual switch and Broadcom’s NIC though with my past experiences with Broadcom hardware, I would tend to point the finger at them.. I have no such problems with the same situation but an Intel NIC. So, it seems that my only real option here is to disable SMTP inspection from the public Internet to my edge email server as even if there is a way to fix the issue on the hosts I have control over, there is no way to fix it on all the virtualized SMTP hosts utilizing this combination that may at one point attempt to send email to my domain... I guess this explains why I am experiencing connectivity issues with SMTP communication from these hosts but not HTTP, since the documentation states that OOO packet processing is enabled by default on layer 7 inspection policies and that the commands are really only there to modify parameters governing it's actions.

As far as the issue I was having with IPv6 under the ZBF, the fix was actually rather simple. I thought that I had at one point attempted to assign an IPv6 ACL to a ZBF CMAP and that it didn't work. I was mistaken... All I had to do was to place a "permit ipv6 any any" in an IPv6 ACL, assign it to a CMAP, assigning that to the top of the individual PMAPs for my zone pairs and all of a sudden, the default drop action as well as specifying IPs for the v4 policy didn't cause a problem with the v6 traffic and I could again be granular with my v4 policies. I am currently using this in conjunction with reflexive IPv6 ACLs and the "ipv6 traffic-filter" commands to basically do a CBAC implementation for IPv6 traffic. I don't know what caused me to try it again. Something just came over me, I guess.. I suppose you could probably use the ZBF for IPv6 traffic so long as you do it all from the command line rather than from CCP, but I don't have time to experiment with it at the moment. Perhaps in the future I will, but the ACLs are doing the job I need for now.