Link to home
Start Free TrialLog in
Avatar of cowanbenefits
cowanbenefits

asked on

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?
ASKER CERTIFIED SOLUTION
Avatar of cmgibson
cmgibson
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of cowanbenefits
cowanbenefits

ASKER

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.
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.
SOLUTION
Avatar of hypercube
hypercube
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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 192.168.58.0/24.
. 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:

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.
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.