Networking / routing between subnets

cowanbenefits used Ask the Experts™
I am not a networking expert... just know enough to be dangerous.

We have a wireless network set up on a Vlan that works great for Internet. We put the guest network on a different subnet to segregate the traffic and also so we could define a different DHCP scope. The APs are trunked via the VLan back to our Watchguard x1250e firewall and the firewall acts as the DHCP server. The problem is that devices on the guest network need HTTP and HTTPS access back to the internal network (for email and internal websites).

To recap:

Wireless traffic is tagged as VLan 2 and trunked through our switches
Switches trunk back to an interface on the Watchguard x1250e firewall which is delegated as a Vlan interface
The  watchguard functions as the DHCP server for the Vlan and works fine
Internal network is
Guest network is
DNS is a server on the network
I can ping devices on the .58 network from the .1 network but not vice versa
Firewall policies are correctly set up to allow HTTP and HTTPS from .58 to .1
Outgoing Internet traffic works fine

I don't really want to mess around too much with subnets because it would throw our main network into upheaval to change all that stuff.

It seems like this is a static route but I'm not sure how to configure it. We have static routes configured for our MPLS WAN to satellite offices, so I've done it before, but putting in a static route to point at the gateway does nothing to fix this.

Can somebody point me in the right direction?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
You will also need to make sure that the DNS server for the .58 network is set to the internal one on the .1 network (DHCP settings on the firewall). You will need a firewall rule to allow DNS traffic (UDP 53) to pass bidirectionally between the .58 and the .1


DNS is configured correctly. DNS resolves to the correct IP addresses but traffic can't even pass to the IPs. I don't think this is a DNS issue... it's an issue with traffic between two subnets.

Are you using Vlan sub-interfaces on the firewall, or do you split the Vlans into separate cables between the core switch and the firewall.
Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!


The Vlans are split into separate cables between the switch and the firewall. The primary LAN (vlan 1) trunks back to a trusted LAN interface on the firewall. That's the The Vlan trunks back to a trusted Vlan interface on the firewall. That's the
Let's see if I understand:

You have LAN (VLAN1?) which uses the Watchguard as the DHCP server.
You have the Watchguard as the Internet Gateway for everything.
You have  VLAN (VLAN2?).
The VLANs terminate at the Watchdog.
I suspect that "wireless" and "Guest" are the same thing / subnet but you didn't really say that.  So, I'm unclear on that.

What is the gateway for the subnet devices?  It appears the Watchguard is set up with a 2nd DHCP server for that subnet / wireless?  So, it sounds like IT is the gateway for them.

You say:
We put the guest network on a different subnet to segregate the traffic
And you also say:
The problem is that devices on the guest network need HTTP and HTTPS access back to the internal network
I can ping devices on the .58 network from the .1 network but not vice versa if that's a bad thing.... ???

Perhaps by "segregate the traffic" you mean more like "bandwidth" instead of "access"?
Because, clearly, these comments and implied requirements seem to be contradictory.

It sounds like DNS is not an issue (by this I mean *internet* DNS and not internal name service).  You haven't mentioned internal name service being an issue (accessing servers by name rather than IP address, etc. between the subnets).

If you want access between subnets then in the simplest sense you need:
- a route from .58 to .1
- a route from .1 to .58
And, no worries about ports at all - let them all communicate.
How this is done is a bit device specific but not too much generally.

Beyond that you can tweak ports as you desire but it's not an up-front requirement.
So, that addresses your first concern about http and https.
But, if you want to *limit* access to only those then you can tweak ports .. but it likely has to be bidirectional as above.

If the switchport that carries the Vlan 2 traffic on the core switch is an access port in Vlan 2, you could make the firewall interface a standard LAN interface. If you have two separate cables there really isn't a need to have the firewall deal with tagging traffic.


Cmgibson, I tried making it a regular LAN port and then the Internet doesn't work.

My above comment was based on the fact that you said,
The Vlan trunks back to a trusted Vlan interface on the firewall. That's the
. I would recommend changing that switchport to an access port and not have the firewall worry about the Vlan

Did you also change the port type on the switch when you changed the other to a LAN port?

If you had left it in trunk mode, the firewall wouldn't have known what to do with the tagged packets. You need to change it to an access port in vlan 2 so the switch strips the tags before forwarding the packets to the firewall


fmarshall: is the primary LAN. It uses a separate Windows server as the DHCP server.
Yes, the Watchguard is the Internet gateway for everything. is VLAN2.

The Gateway for VLAN2 is the VLAN2 interface of the Watchguard.

It's not a problem that I can't ping, I was just throwing that in there as an example. I do want the traffic segregated because I don't want TCP access back to the servers in the network, which is done with firewall rules.

DNS is not the issue. The names are resolving correctly. I can't use external DNS for internal DNS names because the ISP won't route it correctly.


OK cmgibson, I see where you are going with that. Good thought. No, I left the final switch port as a trunk port. I will look into that.


cmgibson, I changed the final switch port to access, untagged on Vlan2. I reconfigured the Watchguard interface as a regular LAN interface. That puts me back in the same place I was... Internet works, local HTTP / HTTPS traffic doesn't. DNS resolves correctly.

I assume you have verified there are no ip based access lists on the intranet sites in IIS? Can you temporarily change the firewall rules to allow all traffic between .58 and .1? This could help narrow down the issue
I don't know what the Watchguard will do but you need port forwards or policy based routing or the equivalent in order to segregate protocols.
Then you need the routes tied to those protocols somehow.
What have you done in that regard so far?


There are no IP based access lists in IIS.

It's not a firewall rule issue between .58 and .1 because they are both trusted interfaces now that I did away with the VLAN interface on the firewall. Firewall rules already allow HTTP and HTTPS traffic from one to the other.

To fmarshall, I have not done anything with port forwards or any routing, policy based or otherwise. Port forwards don't seem right because it is going directly to the correct IP address... there is nothing to forward to. I figure that something needs to be done to route the traffic and this is where my expertise is sketchy.

Make sure "mixed-mode" routing is enabled, but that is really the only routing component that should be involved. I haven't used a firebox before, but I have never seen a device that needs manual intervention for a locally connected route. Also, the fact that you can ping the .58 network from the .1 network proves the route is there otherwise the ICMP packets wouldn't find their way back to the .1 network. This HAS to be a security configuration issue.


There ended up being a firewall policy applied on the wireless access points that was dropping the traffic before it ever hit the switch. I apologize for wasting time on this one... I went through a couple of hours of support with the wireless folks before coming here with the question and they were confident it was a routing issue with the firewall. I finally plugged directly into the switch and figured out that it worked without the wireless in play which led me back to the wireless support.

Splitting the points on this one proportional to the amount of help offered.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial