To start, let me say that I am a little new to this stuff.
My question is how to properly implement self zones in zone-baed firewall to keep IPSec VPN working.
Currently I have successfully created site to site IPSec VPN connections between 6 routers (1 hub, 5 spokes). For the firewall testing, I'm using just one hub and one spoke. These are non-VTI configs so the cyrpto map is bound to the WAN inteface (gig0) of these 891W routers.
So, VPN works fine, can ping LAN to LAN no problem . I also have NAT configured on both rotuers (spoke has just nat overload and the hub has overload plus some static NAT for outside access to email server and web server). I've made the NAT exceptionis in the VPN config so LAN to LAN traffic goes through the IPSec tunnel and anything else goes in/out the regular WAN interface.
I am now attempting to layer on the zone-based firewall (ZFW). So far I am putting the firewall only on the hub router.
I have Inside to outside and outside to inside zones set up and working with some fairly basic inspection.
The trouble begins once I start using self zones to enable management access. I definted just the outside-self zone, and enabled pass log for ssh (inspection of ssh is not supported for self zone). This works, however my ability to ping LAN to LAN through VPN no longer works.
I'm having difficulty conceptualizing the flow of things but here's what I think: This is a non-VTI VPN config, so again crypto map is bound to WAN inteface, which is an interface that would be part of the self zone by default. Without any zone-pairs that have self in them, the default ZFW policy is to allow all traffic to/from Self. But as soon as I create a zone-pair involving Self and apply policy to it, now it's a deny-all except what I allow for. Not sure if this is correct but it seems to behave that way.
On the hub router I created an ACL permitting all IP's from the spoke router's LAN to all IP's on the hub router's LAN and put this in a class map, then stuck that class map in the existing single OUTSIDE-SELF policy map and added the inspect action to this second class map. Still could not ping LAN to LAN though. So I added to this same ACL a permit ip entry for the reverse, so LAN traffic from the hub router t the LAN side on the spoke router. Example:
access-list 150 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
access list 150 permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255
Once I did this, it works, pinging between LAN's now happens.
So my question first is, why wouldn't the inpsect action allow that to happen, and, is this 2-line ACL the best way to go about solving this?
I did read the white papers on ZFW Design and also the one about using IPSec VPN with ZFW, but though both mention to use an ACL to allow hosts from one LAN to another through VPN, it really didn't make anyh sense nor discussed in any detail what could go wrong etc.
Also I"m open to any other advice but since I'm not well versed in this stuff, I would rather work within the confines of the existing non-VTI config.
Ok nevermind, this config does not work. A few minutes after posting, I found that LAN 2 LAN ping no longer worked. Couldn't figure out why so I wiped away the zone-pairs, policy and class maps related to the self zone. Everything worked fine after that, so I rebuild the self zone stuff one more time. Again, pings over the VPN tunnel worked for a bit, thne a few minutes later just stopped.
I have no clue. Going to set this post up as a service request with the TAC.
Hope to work with you on the TAC case tomorrow
As the case has been closed please mark the question as answered
What is the protocol for marking it answered? Normally I would take the post in the thread with the answer but in this case there are n posts with the answer, just the reference to us and a TAC case. Would I just pick the first post you made?
I think so, but it's been 2 years. Wow time flies. I still recall the impression I had of your excellent help though as well as our friend in Costa Rica. I don't recall the specifics of this case but I am fairly sure we fixed it since the router has been working ever since. I wish I had more time right now to review the entire thread but got to get to work. Which post would you say I should mark as answer? happy to do so as I didn't realize I left this one undone.