ZBFW expected behavior?

[b.julin]

Kinda new to the zone based firewalling stuff, and the IOS-XE firewalling is a bit new and may still have bugs, so I need to know from someone running a more mature ZBFW implementation whether this is expected behavior:

If you have traffic that goes through a Pass when traveling from zone1 to zone2, but then the return traffic hits an Inspect on the way back, it seems to get dropped.

This doesn't seem right -- it would require the reverse policy to have a duplicate set of rules so it knows which traffic came in via a Pass and which would have been dropped and needs to have pinholes knocked through...

zone-pair foo source zone1 dest zone2

service-policy type inspect zone1_zone2

zone-pair bar source zone2 dest zone1

service-policy type inspect zone2_zone1

policy-map type inspect zone1_zone2

class protected_subnet

Drop

class restofthenetwork

Pass

policy-map type inspect zone2_zone1

class inspect_outgoing

Inspect

class-map type inspect protected_subnet

match access-group name protect

class-map type inspect restofthenetwork

match access-group name ourroutables

class-map type inspect inspect outgoing

match protocol udp

match protocol tcp

match protocol icmp

With the above traffic from outside to restofnetwork goes through but the return traffic hits class inspect_outgoing and drops. I know it's not another ACL because if I change the action to pass it works (and, of course, at that point the protected network can no longer make outbound connections.)

[sadsiddi · Accepted solution]

This is expected.

One basic question, if you want a certain type of traffic say TCP to go frm zone1 to zone2 and vice verssa, why not having Inspect on the fwd policy itself?What is the traffic that you are running which you need to pass on forward direction and inspect on the reverse direction?

Shouldnt your reverse policy look like something:

policy-map type inspect zone2_zone1

class protected_subnet

Drop

class restofthenetwork

Pass

class inspect_outgoing

Inspect

[b.julin]

The problem here is that "restofthenetwork" is actually a several hundred line long access list being imported from an ASA, so that's several hundred lines long before network and service object groups are exploded. Which means to keep things scalable configuration-wise, we have to emulate the object and network groups using match-all class-maps.

It looks like the option of just inspecting the traffic on the way in will have to be tried, but it exposes us to resource depletion as it will create sessions in the ASR for all the garbage probing traffic that the hosts would normally reject on their own.

The other option seems to be to install a duplicate, reversed copy of that massive access list and maintain both concurrently.

Neither option is particularly attractive. Some sort of hybrid between the two to find and pass a portion of the uninteresting traffic might work, but it seems like something IOS should be able to be told to do automatically.

Thanks for the answer. Out of curiosity, do you happen to know what happens if traffic is inspected as, say, TCP in one direction and the return traffic hits a protocol-specific inspect statement like match proto ftp/inspect?

[sadsiddi]

I understand your concern. But IOS today doesnt have this.

And regarding tcp on forward and ftp on reverse, the SYN to port 21 would match TCP and hence only Layer 4 inspection would happen for the reverse traffic regardless of FTP on that direction which would prevent data channels to be opened. Such mis-configurations should be avoided.

[b.julin]

Thanks again. Not to belabor the point, but due to the way inspect policy-maps and match-all class maps work, that means in certain situations that one class and policy map rule will be needed for each individual protocol at each point in the access list where an inspect is warranted. I understand however, the sub-class-map feature on the roadmap will ameliorate this problem in future releases.

.o0(how cool would a "match access-group-backwards" feature be...)

[sadsiddi]

I will discuss this with my team here and let you know the outcome.