Networking / routing between subnets

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 192.168.1.0/24
Guest network is 192.168.58.0/24
DNS is a server on the 192.168.1.0/24 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 192.168.1.0/24 at the gateway does nothing to fix this.

Can somebody point me in the right direction?
cowanbenefitsAsked:
Who is Participating?
 
cmgibsonCommented:
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
0
 
cowanbenefitsAuthor Commented:
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.
0
 
cmgibsonCommented:
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.
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
cowanbenefitsAuthor Commented:
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 192.168.1.0/24. The Vlan trunks back to a trusted Vlan interface on the firewall. That's the 192.168.58.0/24.
0
 
Fred MarshallPrincipalCommented:
Let's see if I understand:

You have LAN 192.168.1.0/24 (VLAN1?) which uses the Watchguard as the DHCP server.
You have the Watchguard as the Internet Gateway for everything.
You have  VLAN 192.168.58.0/24 (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 .58.xxx 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
And:
I can ping devices on the .58 network from the .1 network but not vice versa
....as 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.
0
 
cmgibsonCommented:
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.
0
 
cowanbenefitsAuthor Commented:
Cmgibson, I tried making it a regular LAN port and then the Internet doesn't work.
0
 
cmgibsonCommented:
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 192.168.58.0/24.
. I would recommend changing that switchport to an access port and not have the firewall worry about the Vlan
0
 
cmgibsonCommented:
Did you also change the port type on the switch when you changed the other to a LAN port?
0
 
cmgibsonCommented:
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
0
 
cowanbenefitsAuthor Commented:
fmarshall:

192.168.1.0/24 is the primary LAN. It uses a separate Windows server as the DHCP server.
Yes, the Watchguard is the Internet gateway for everything.
192.168.58.0/24 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.
0
 
cowanbenefitsAuthor Commented:
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.
0
 
cowanbenefitsAuthor Commented:
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.
0
 
cmgibsonCommented:
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
0
 
Fred MarshallPrincipalCommented:
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?
0
 
cowanbenefitsAuthor Commented:
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.
0
 
cmgibsonCommented:
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.
0
 
cowanbenefitsAuthor Commented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.