Inter VLAN Routing - Internet Access
-
Ha! Netgear has them as routing vlans. Just using their terms. :D There is a separate tab in the switch to create routing vlans and has a "van routing wizard". Though in the end you can make changes to all vlans in the main vlan configuration page.
Check this …http://kb.netgear.com/24709/How-do-I-use-the-VLAN-Routing-Wizard-on-a-smart-switch?cid=wmt_netgear_organic
And this is the routing vlan doc from netgear I referred to earlier.
http://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR-managed-switch-with-shared-internet-access?cid=wmt_netgear_organic
There is no mention of a transit ip. And in the end they use a netgear gateway for static routing.
OK so I will do the below.
Vlan 10 - 10.1.1.1 - ip on virtual port for lan (it's usually 4/1 on my switch)
Vlan 20 - 10.1.2.1 - ip on virtual port for voip (4/2)
Vlan 30 - 10.1.3.1 - ip on virtual port for video (4/3)
Vlan 40 - 10.1.4.1 - ip on virtual port for home (4/4)Vlan 100 - 172.16.1.1 - transit ip to pfsense (4/5)
172.16.1.2 - transit ip (single lan ip) on pfsenseLet me know if this is right.
-
Wow – what a shitty document..
So they create asymmetrical routing condition… Since you have hosts on what is your transit network ;)
So they show to set the gateway of clients to be the switches IP in their "routing vlan" 192.168.10.254.. So I have a client that is on this 192.168.10 say .100, where does it send its traffic to get to the internet.. its gateway is .254 the switch, who then sends it on in the same network to the router at internet gateway at .1. Now when that traffic gets back, where does it send it? To the client directly, why would it send it to .254? So now you have asymmetrical condition..
Yeah wouldn't in a million years set it up like that.. If your going to put hosts on your transit, then you have to host route on them or you end up with hairpins and asymmetrical conditions. And with a firewall in play as well that leads to trouble with out of state traffic..
-
This is the very reason I opened this thread.
OK so now did go ahead and wiped all vlans and created a new set of vlans as per my post above.
The devices within vlan 10 to 40 and 100 can ping each other and I can ping the virtual ips of each vlan.. like 10.1.1.1 and 10.1.2.1..
Now I have a new issue. Transit ip on switch 172.16.0.1 can't ping back to pfsense ip 172.16.0.2. From pfsense I can ping the switch transit ip 172.16.0.1 successfully.
-
So look at your firewall rules.
Where traffic needs to exit the firewall there has to be a route telling it where to go. (Policy route, connected interface, static route, default route.)
Where traffic needs to enter the firewall there has to be a rule allowing it to enter.
-
Tried that already.
Here is my pfsense LAN (transit) firewall rule
IPv4 * 172.16.0.1 * 172.160.0.2 * * none Switch to Firewall
IPv4 * LAN net * * * * none Default allow LAN to any ruleIPv6 * LAN net * * * * none Default allow LAN IPv6 to any rule
I have the LAN (transit) cable coming from pfSense on port 44 on the swtich.
On the switch, I have vlan 100 with port 44 untagged. If I tag it I can't ping from pfSense. No other port is enabled on that vlan. The switch transit ip is 172.16.0.1 and pfSense is 172.16.0.2.
I even tried assigning an IP directly to the port in IP Routing tab on the switch. Same results, can ping from pfSense but not from the clients inside the vlans.
-
Looks like a typo here:
IPv4 * 172.16.0.1 * 172.160.0.2 * * none Switch to Firewall
16 != 160
-
Just a typo .. it was 30 past midnight 8)
It's 172.16 on pfsense.
-
So all those rules allow is switch to talk to pfsense.. Doesn't allow any of your other traffic..
You have all your downstream networks, your transit interface rule has to allow for that. I went over that in 1st post.. Your switch is not NATTING to its IP in the tranist..
Also its much easier to post screenshot of your rules..
-
OK.. finally some progress. I connected to the transit network just to get my head around it and saw that I could connect to both 172.16.0.1 (switch) and .0.2 (pfsense) and the internet was working. But I of course couldn't ping 10.1.1.0/24 network on the switch. So I added a new gateway on pfSense for the LAN 172.16.0.1 and in static routing I pointed the network 10.1.1.0/24 to it. That got me reach to 10.1.1.0/24 netowork on the swtich. I then added a static route on pfSense for destination 10.1.1.0/24 use the gateway 172.16.0.1. That got my 10.1.1.0/24 network to start pinging the pfSense and the outside world.. 8.8.8.8
-
your outbound nat has to be adjusted to outbound nat your downstream networks.
I am on the default "Automatic outbound NAT rule generation." and my internal switch network is pointed to pfSense LAN (transit ip) 172.16.0.2 for DNS and its working. Am I doing this right? If not, then could you please guide me on what the setting need to be?
-
Dude post up your outbound nat.. How is psense going to know to nat these downstream networks when it doesn't have them directly connected..
You don't need to create multiple routes for all your /24's on pfsense - just use a summary route. They are all in the 10 space, so 1 route to 10/8 gets you to your switch. On your switch pfsense is internet, so that is the default route..
-
I didn't even touch the outbound nat. I think it took the static routes and updated the mappings. All I did is create static route for each subnet and pointed the transit ip as the gateway.
Here is my automatic outbound nat.
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 127.0.0.0/8 10.1.1.0/24 10.1.2.0/24 10.1.3.0/24 10.1.4.0/24 172.16.0.0/30 * * 500 WAN address * Auto created rule for ISAKMP
WAN 127.0.0.0/8 10.1.1.0/24 10.1.2.0/24 10.1.3.0/24 10.1.4.0/24 172.16.0.0/30 * * * WAN address * Auto created rule -
I then added a static route on pfSense for destination 10.1.1.0/24 use the gateway 172.16.0.1. That got my 10.1.1.0/24 network to start pinging the pfSense and the outside world.. 8.8.8.8
So what's still not working?
-
The comment by johnpoz "your outbound nat has to be adjusted to outbound nat your downstream networks." got me thinking if I may be missing something that needs to be in place not to break the routes and if its not working the way it should.
Hey as long as I don't have to manually change the settings I am a happy camper ;D
Now if there was a way just to get pfSense DHCP relayed to the downstream networks it would had been icing on cake. I think I will move pfSense back to vmware and install a dhcp vm on the same hardware. With all my vlan traffic now handled by the switch I barely see any CPU usage on pfSense.
-
You could also probably just DHCP in your switch.
-
You could also probably just DHCP in your switch.
Yup that's what I am using currently but its not full fledged as I need it. Have squid proxy dhcp options plus a ton of dhcp static ip assignments which are a pain to manage or configure on the switch.
I may need to start a new thread (or just use this one) as I have to do the same inter vlan routing for ipv6 to the outside world which is tunneling through HE. At the moment its completely broken in the new network. Was working fine when pfSense handled this.
-
You don't need to create multiple routes for all your /24's on pfsense - just use a summary route. They are all in the 10 space, so 1 route to 10/8 gets you to your switch. On your switch pfsense is internet, so that is the default route..
Thanks I will remove the routes and use the summary route. Makes managing the routes a bit simpler :)
-
You could also probably just DHCP in your switch.
Yup that's what I am using currently but its not full fledged as I need it. Have squid proxy dhcp options plus a ton of dhcp static ip assignments which are a pain to manage or configure on the switch.
I may need to start a new thread (or just use this one) as I have to do the same inter vlan routing for ipv6 to the outside world which is tunneling through HE. At the moment its completely broken in the new network. Was working fine when pfSense handled this.
Dual-stack the transit interface using a /64 out of the /48 (you might be able to get more clever here, but I wouldn't for now.)
Probably just route a /56 out of the /48 to the switch and assign interfaces out of it there. You will have 256 /64s to play with.
Default IPv6 route back to pfSense transit.
Then just pass source traffic from that /56 on the pfsense transit interface.
-
Yeah if you want ipv6, you just need to do the same thing via ipv6 transit which could just be link-local. Doesn't have to be one of your /48 from HE.. But with a /48 you have plenty of /64s to play with so yeah you could use one as your transit network. This would make for fully functional traceroutes, etc.
https://tools.ietf.org/html/rfc7404
Using Only Link-Local Addressing inside an IPv6 NetworkAs to your dhcp relay problem - its been brought up quite a bit leveraging pfsense dhcp for pools that pfsense does not have an interface in that network.. I am not sure if that is going to be a future feature or not. But it has come up quite a bit for long time.
Personally I could care less.. If you have come to the point where you network is larger and more complex (ie using downstream routers) you prob should have a dedicated dhcp system with failover, centralized,etc etc. While I agree with you the dhcp server feature list on switches prob going to be limited and interface and or config prob clunky compared to simple gui pfsense has put in place.
If you have vm infrastructure already in place just fire up VM for your dedicated dhcp, etc. Prob want to match that up with your local dns so you can resolve your dhcp clients or reservations, etc.
-
Yup, doing that exactly on VM. Just that I have a dependency on a vm for DNS/DHCP which is not what I am a fan of. Anyways I installed a 2.4 snapshot last night on VM and got the network back up. Now getting the DNS/DHCP in place.
I will resurrect this thread in a day or two as I would need some hand holding on the IPv6 part as I am not comfortable with IPv6 yet as much I am with IPv4 which I did on a regular basis back in 1998. (Windows NT… good old days)
