Traffic Flows from CLIENT > Cisco 3850 >(10.10.10.225) Watchguard Firewall
We added a DMZ VLAN and setup the ACL so 192.168.0.0 traffic can't talk to 10.10.0.0/16 traffic.
I have a separate interface on the firewall setup for the physical link to the switch/DMZ using the ip 192.168.5.2/30, so on the switch I wanted to use 192.168.5.1/30 as the default gateway for the 192 traffic. Keeping it completely separate from the 10 network. The clients on the 192 network will use the 192.168.200.0/24 ip addresses.
Is this possible? Am I not thinking about this the right way?
To make this work, you'll need to configure VRF-lite on your 3850.
Assuming on your 3850 that gi1/0/1 is connected to the 'inside' watchguard interface and gi1/0/2 is connected to the 'dmz' watchguard interface you'll need something like this:
*** 3850 ::
ip vrf dmz
int vlan 10
ip address 10.10.10.224 255.255.255.0
int vlan 11
ip address 10.10.1.254 255.255.255.0
int vlan 20
ip vrf forwarding dmz
ip address 192.168.5.2 255.255.255.252
int vlan 21
ip vrf forwarding dmz
ip address 192.168.200.0 255.255.255.0
switchport access vlan 10
switchport mode access
switchport access vlan 20
switchport mode access
ip route 0.0.0.0 0.0.0.0 10.10.10.225
ip route 0.0.0.0 0.0.0.0 192.168.5.1 vrf dmz
...I've taken a guess at your inside p-to-p config :)
I'm thinking this is exactly what I want. We figured out that clients can use the ip address on the firewall as their default gateway. But the switch can't ping out. I think this will help and I'll add it to my maintenance tasks to do in our next maintenance window.
If the switch can't ping out then it is likely an issue with return traffic. Does the firewall have routing entires for all the 'inside/dmz' subnets?
Going by my config does it have the following entries:
192.168.200.0 255.255.255.0 gw 192.168.5.2
10.10.1.0 255.255.255.0 gw 10.10.10.224
? Or perhaps you are using aggregate routes:
192.168.0.0 255.255.0.0 gw 192.168.5.2
10.10.0.0 255.255.0.0 gw 10.10.10.224
If the clients only need to access the firewall and beyond and never the 10.10.x.x clients then there is little point in using VRFs.
As you say just make the clients default gateway the firewall interface IP.
You can use VRFs but it is a fair bit of extra configuation for no gain whatsoever.
The DMZ network has two subnets in use, the switch/firewall p-to-p and the DMZ subnet itself.
Wouldn't the DMZ clients need a default gateway of the DMZ subnet SVI (typo in my original config -> ip address 192.168.200.254 255.255.255.0). Therefore the switch would need to maintain two routing tables?
Agreed, if the OP configured the firewall DMZ interface as a /24 and had that on the switch as a Layer2 VLAN, then VRFs would be unnecessary.
Agreed, if the OP wants to use a P2P link from the switch to the firewall then VRFs are needed.
It was just because in the original post he mentioned using a separate interface on the firewall it just seemed to me easier to extend the vlan to the firewall.
But yes using a P2P you do need VRFs.
I made a change and went with a straight /24 on the 192. so the VLAN ip is 192.168.200.220, the firewall interface is 192.168.200.225. The clients using 225 as the gateway can get out to the internet. Now I'm assuming some firewall configuration will need to be done so that an ADFS web proxy on 192 can hit the DC on 10?
Sorry for the lack of knowledge here.
Two slightly confusing things here -
1) why have an SVI on the switch with 192.168.200.220, why not just use the .225 IP as the default gateway ?
2) that said, I thought you said there was no communication between 192.168.200.x and 10.10.x.x but you seem to be suggesting there is now ?
If there is Seb's solution of VRFs may be the way to go although you will need to do route leaking between VRFs.
1. I guess I don't need the .220 IP anymore for the VLAN, so I can probably drop that.
2. I totally understand that this sounds completely stupid based on me saying these can't talk to each other. However, I'm a bit confused on how the web proxy server (workgroup vm) talks to the Active Directory Federated Domain which is on the internal network.
If it needs to talk to your AD you have 3 options -
1) route the 192.168.200.x clients on the switch and use an acl on the SVI to only allow the web proxy to talk to AD
2) as above but instead of using acls use VRFs as per Seb's example and then add a route for the AD server to the VRF and add a route back as well
3) use the firewall as the default gateway and add a rule allowing the web proxy to talk to the AD server
Which you use depends on your topology really.
Personally if possible I would do it on the firewall because it is more secure that way but any of the above would work.
Seb may also have other options I have missed.
Thank you for all your input so far, I really appreciate both you and Seb helping out.
We added a SNAT on the firewall that should handle the traffic hitting internal networks.