You set up the peering with the provider(s). They will send you routes based on their configuration. You should talk your provider. If you aren't multi-homed, you can just get a default route from them.

Added a Rule to allow all AWS to Remote…..now traffic works but now the issue has flipped....adding a rule to the Remote site has no impact/effect for traffic going the other way.

AWS to Remote now works.....before it didn't

Remote to AWS now FAILS.....before it worked.

All I added was a rule on the AWS Side for each remote site Example..... Allow all traffic source 172.31.0.0/16 destination 10.0.96.0/19

I am confused I tried adding a static route on the Remote site....(using the same above example) but it won't take the open VPN ip as a gateway (192.168.0.40.1), and using 10.0.96.1 does nothing.

Not sure if pushing a route via the OpenVPN connection would solve this.

Do it right.

Tell your ISP to give you a small WAN interface subnet for your WAN interface, say a /29 or /30, and to route the /28 to that instead of putting so many addresses on the interface.

Then you can do what you want how it should be done without this hacky bridging.

Ah ok.. Then your good.. there should be no untagged traffic hitting that port the way you have it setup.. Just know that if any untagged traffic does get onto that port from pfsense it would go to your default vlan on the switch.

To follow through with good practice you should limit your trunk port to those specific vlan IDs, 10,11,20 and 50.

Trunk ports will allows allow for untagged traffic, and if you do not call out what vlan untagged should be assigned to with the native vlan command then untagged traffic will go to whatever the default vlan is on the switch.

I just run a native vlan on my interface, and then run vlans on top of that.  But your way is also very common.  I do believe Derelict is a fan of only tagged traffic and not using any untagged traffic.

Glad you got it all sorted.. In the cisco world if your not going to run a native or untagged vlan on the interface then you would normally use general for the port and assign the tagged vlans and setup the port to only accept tagged traffic, etc.  Where any untagged would go to garbage vlan ID.  Lots of different ways to skin the cat ;)

Also bit of a side note with just using trunk vs limiting the vlans on the trunk port.  Any other vlans you might be running on the switch - broadcast traffic could go down that port.  It won't go anywhere since pfsense doesn't have any vlans setup for other IDs.  But broadcast traffic would be sent down that trunk port since you have set for ALL vlans with just the trunk command.  Blanket trunk commands like that are normally frowned upon.  You normally limit the trunk to the specific vlans that that are ok to travel on that port.

Thanks for help guys

Is this the routing table you need?  Or dod I need to type something at the command line?

default 192.168.0.7 UGS 909 1500 igb0 8.8.8.8 192.168.0.7 UGHS 267666 1500 igb0 127.0.0.1 link#6 UH 391288 16384 lo0 192.168.0.0/24 link#1 U 8182 1500 igb0 192.168.0.8 link#1 UHS 0 16384 lo0 192.168.2.0/24 link#2 U 3033066 1500 igb1 192.168.2.1 link#2 UHS 0 16384 lo0 199.193.201.12 192.168.0.7 UGHS 175810 1500 igb0 208.67.220.220 192.168.0.5 UGHS 413247 1500 igb0

"MICHAELMAINPC uses 8.8.8.8 as Primary DNS. The secondary will be only requested if the primary is not reachable,"

I want to clarify this with some more info, since it comes up ALL THE TIME!!!  It is NEVER a good idea to set different ns on a client.  You can set multiple dns sure.. But they all need to be able to resolve the same info.. So if your going to use public fine - use public..  Google and Open for example… But you should never set a public and a local dns.. Since public is not going to be able to resolve your local stuff.

If you want failover and redundancy then point to multiple local dns that can all resolve your local stuff, let them forward or resolve for all public stuff.

You really can never be sure when a client will query the NS listed..  And as mentioned if you ask google for say www.somelocaldomain.tld its going to send back NX.. Client will cache that that domain is not valid, its not going to ask any other ns it has listed for that.. Until such time that neg cache expires, etc.

You will only be asking for problems trying to use different NS that can not resolve the same stuff.. Point your local clients to local dns, let the local dns go find the public info..

you can manually add your gateway for the interface then edit the gateway and under advanced settings check "use non-local gateway" (pfsense 2.4.2)

I use almost same config. I guess you use KPN or XS4ALL?

For upstream networks in IGMPProxy only use: 213.75.0.0/16, 10.196.0.0/16 or 10.0.0.0/8
Do not include the 192.168.x.x (Lan IP range).

For Firewall rules you need to enable:

On IPTV WAN interface:
IPv4 UDP  *  *  224.0.0.0/4  *  *  none        UDP Multicast stream from any to 224.0.0.0/4
IPv4 IGMP  *  *  *  *  *  none      IGMP IPTV allow all    [Also enable advanced IP options on this one]

*Remove the other rules

On LAN interface:
IPv4 *  LAN net  *  *  *  *  none      Default allow LAN to any rule    [Enable advanced IP options on this one]     
IPv6 *  LAN net  *  *  *  *  none      Default allow LAN IPv6 to any rule

I don't understand how I missed this 'import' button.. Now it works. Thanks!

And also thanks for idea of updating list with pfBlocker - I'm new to pfSense, didn't know about this package (and now I have an idea of creating package which will auto-create/update aliases based on openvpn routes).

" each their own subnet / switches and firewall's / own dhcp /dns"

If these switches are separate connect them… So once a client connects to the specific ssid/vlan they can get to either side.. forget about the routing between these networks - you do not need to do that until the networks join into 1.

But really easy leverage all the AP for both networks - where clients can be put on any network you want via the vlan and that ssid, or the dynamic vlan.. As long as the switches the AP connect to are managed this is simple setup.

Does this drawing help.

Does not matter what brand firewall is on the side - your just doing doing everything at layer 2 with vlan IDs.. As long as the switches share the same vlan IDs for the different networks you can let traffic flow wherever you want be it to pfsense or the other firewall, etc.  Clients will be on the vlan they join via ssid, etc.

thishelp.png_thumb
thishelp.png

What I suggested completely bypasses the round-robin configuration since you are explicitly policy routing to that WAN. As long as those policy routing rules are higher in the rule set.

Use frr instead of OpenBGPd. It appears to be fixed if using that combination.

@chpalmer:

@rast4man:

Now that I think about it, bridging the modem would lose my NanoBeam bridge over 5ghz. This is how I currently get my network so that's a bust.

Using their modems built in Wifi?

Yes. Since I rely on the NanoBeam for the bridge, if I put the modem in bridge, I'd have to put an AP on their side and recreate the bridge. I don't have the ability to hard wire their modem to my equipment. Essentially, this is a huge PITA.

Thank’s for yours replies, I try it.