We are testing the use of layer 3 switching, trunking, and VLAN subinterfaces with the (4) INSIDE networks. Layer 2 and Layer 3 pings are working at the switch, however from the subinterfaces on the firewall they can only see their subnet.
Pinging from systems on the subnets can see their subnets but not the others.
IP routes show connected on both the switch and firewall. Only INSIDE subnet is getting out to the OUTSIDE interface, the other 3 are isolated for some reason.
Gateway of last resort is xx.xx.61.1 to network 0.0.0.0
C xx.xx.61.0 255.255.255.0 is directly connected, OUTSIDE
C 172.16.1.0 255.255.255.0 is directly connected, DMZ
C 192.168.102.0 255.255.255.0 is directly connected, vmKERNEL
C 192.168.1.0 255.255.255.0 is directly connected, INSIDE
C 192.168.2.0 255.255.255.0 is directly connected, prodPS
C 192.168.101.0 255.255.255.0 is directly connected, vmCONSOLE
S* 0.0.0.0 0.0.0.0 [1/0] via xx.xx.61.1, OUTSIDE
Gateway of last resort is not set
C 192.168.102.0/24 is directly connected, Vlan202
C 192.168.254.0/24 is directly connected, Vlan911
C 192.168.1.0/24 is directly connected, Vlan101
C 192.168.2.0/24 is directly connected, Vlan102
C 192.168.101.0/24 is directly connected, Vlan201
We are getting portmap translation errors in reference to the other 3 INSIDE networks which all have the same security level of 100.
We have been looking at this too long, can't see the forest thru the trees.
I am assuming that the only interface is that is able to go out to the internet is PROD-RS - VLAN 101 is that correct? Well this actually makes sense and let me explain you why.
Lets say that you are sitting on the vlan PROD-PS - VLAN 102, this are the steps (based on your routing) on how a packet would flow when going to the outside:
-It is going to go from the computer to the Layer 3 switch
-From the layer 3 switch its going to pick up the default route which poing to 192.168.1.1 and head the the PROD-RS - VLAN 101 interface of the Firewall
-Then the return packet from the outside comes to the firewall with a destination that is directly connected to it and it is going to try to send it to PROD-PS - VLAN 102
-The problem is that the firewall already has an state entry that says that the packet first went out throuh the interface PROD-RS - VLAN 101, and then since it is not the same interface as it was when it went out, the packet will be discarded. (Because of asymmetric routing)
Nature rule of every Stateful Firewall, if packet goes out on one interface, the return packet should be send on the same one.
But, why does it work with the Vlan 101?
The packet enters and leaves on the same interface, opposite on what happens when you start a connection on Vlan 102, or any other vlan.
I am pretty sure that if you change the default route on the switch to be 192.168.2.1, everyone on that vlan will be able to access the outside interface but Vlan 101 and the rest would be blocked.
How to solve this?
If you want to protect your Network on an effective way, I would recommend you to have the routing being done only on the firewall, thus disabling routing capabilities on the switch and leaving only the l2 Vlan segmentation.
If you have any doubts, please let me know, I would be more than glad to assist.
I disagree slightly with your trace since all 4 subnets are trunked to the firewall using VLAN subinterfaces. The gateway of last resort is the OUTSIDE interfaces' peer at the ISP. Each VLAN is designated on the firewall have their own gateways.
The ip default-gateway actually doesn't apply in the switch configuration (even though it is defined) since Layer 3 routing is enabled and the gateway of last resort is defined on the firewall.
We tried disabling ip routing on the switch but the results were not much better.
If we went to layer 2, then we would have to remove the subinterfaces and VLANs from the firewall, remove the trunk, and implement a Layer 3 switchport on the switch then define static routes on the firewall -seems to be the best practice recommendation.
Not sure which is more effective or best practice.
Things to consider, in the future we have to implement VPN access that has issues with hairpins. Trying to keep things more flexible without excessive manipulation of the NATs (static) especially before upgrading to v8.3.
I think my issue is more about NAT since they are dynamic and not static since we only get portmap translation issues on the firewall for VLANs 102, 201, and 202.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...