I have two VLANs: My production VLAN (VLAN0, 192.168.1.x) and my public-wifi VLAN (VLAN2, 172.16.1.x). This is done for PCI compliance, so I have “inter-vlan routing” disabled. This way, all guests on VLAN2 have no access to any of our production servers. (I feel this is a common configuration) On my production VLAN is my webstore (192.168.1.210), which has an Inbound Access Server/Service rule set up to forward incoming http/https traffic (store.mydomain.com:80) to the server (192.168.1.210:80).
When connected to VLAN0 (say 192.168.1.55), you can connect to the webstore (store.mydomain.com) just fine. The balance detects that the outgoing destination resolves to a WAN IP, so it handles that according to the inbound traffic rules, and redirects it to my webstore server (192.168.1.210, also on VLAN0).
However, when connected to VLAN2, a connection to store.mydomain.com does not succeed. I assume this is because it detects that store.mydomain.com resolves to the WAN IP, applies the inbound traffic rules to it, but then ultimately rejects it because a request from 172.16.1.x to 192.168.1.210 is not allowed, according to a strict definition of “inter-vlan routing” disabled.
So my feature request: I would like an exception to be made to the “inter-vlan routing” rule. When inter-vlan routing is disabled, I would like data from one VLAN to another be allowed when it is forwarded from an Inbound Access Server/Service rule. This way, guests on my public-wifi, VLAN2, can connect to my publicly available webstore on VLAN0.
Please ensure users in subnet 192.168.1.0/24 and 172.16.1.0/24 resolve store.mydomain.com as 192.168.1.210. You may achieve this by adding Local DNS Records in Balance router. Network > LAN > DNS Proxy Settings > Local DNS Records. Ensure clients point Balance router as DNS server.
Thanks for your reply. I was finally able to test this out. It seems to be working OK.
However, users in my guest wireless subnet (172.16.1.0/24) are still able to connect to the peplink configuration page, 192.168.1.1. Using the firewall rules you set above, a user from the 172.16.1.0/24 subnet shouldn’t be able to connect to 192.168.1.1. Am I doing something wrong?
store.mydomain.com resolves to the WAN1 IP address, not 192.168.1.210. When I connect to https://store.mydomain.com from the guest wireless subnet, I get a certificate error, “403 Forbidden”, Server’s certificate does not match the URL. Under certificate information, it is using a certificate for captive-portal.peplink.com, instead of the certificate for store.mydomain.com.
When I add a local DNS record, as you suggest above, it sort of fixes the problem. However, this doesn’t work for everything. For example, I host streaming video on 192.168.1.210:1935. I have a server/service set up for port 1935 on all WANs to forward incoming traffic to 192.168.1.210. The hostname stream.mydomain.com points to the WAN IP. However, I forward other ports to servers that are not 192.168.1.210. SO, I can’t add a local dns record for stream.mydomain.com. As a result, connections to stream.mydomain.com:1935 from the guest-wireless with captive portal fail.
The problem is that I have stream.mydomain.com configured to forward to different IPs based on the port, using the inbound access > servers/services. For example, stream.mydomain.com:1935 routes to 192.168.1.210:1935, whereas stream.mydomain.com:xxx routes to 192.168.1.211:xxx, etc. So adding a local dns record for stream.mydomain.com to point to 192.168.1.210 will cause the other services/ports to stop functioning.
This works fine without the local DNS record in non-captive portal VLANs. For example, a connection to stream.mydomain.com:1935, which resolves to the cable modem WAN IP, is correctly forwarded to 192.168.1.210:1935 using the inbound access -> servers/services that are configured. The problem only seems to happen with captive portal.
We will support NAT loop back access with Captive Portal in future release.
For workaround, I do encourage to use unique hostname for each server. For example, store.mydomain.com is referring to 192.168.1.210 and stream.mydomain.com is referring to 192.168.1.211.