Messages

1

Virtual private networks / Re: Wireguard Selective Routing - Why Step 9?

« on: February 27, 2023, 02:59:42 pm »

Based on the thread, it appears that Unbound cannot use the wireguard gateway since there is no IP address in the wireguard interface. As a result, some outbound queries use the wireguard address as the source (root domains as the target) but are routed through the WAN interface using the default route. The rule in step 9 forces these packets to be routed through the wireguard gateway.

Is the description above correct?

2

Virtual private networks / Wireguard Guidance - did I do it correctly?

« on: February 20, 2023, 11:51:08 pm »

Apologies for the long read.

I’m trying to setup a wireguard VPN tunnel that allows the following:
1. Inbound connection from a road warrior.
2. Site to site connection with other wireguard peers
3. Selective routing from LAN hosts to wireguard server as gateway to the internet.

As such, I’ve read all the guides on the opnsense website in hopes of coming up with the correct configuration.
I would appreciate any advice/insight if I’ve made a mistake (or anything I can improve on).
Wireguard Network: 10.0.10.1/24 (wireguard server is 10.0.10.1/32)
Home LAN network: 10.0.0.1/24, 10.0.1.1/24 (wireguard peer is 10.0.10.2/32)
Remote LAN network: 10.0.2.1/24 (wireguard peer is 10.0.10.3/32)
Roadwarrior: varies (wireguard peer is 10.0.10.4/32)

On HOME opnsense server:
    1. Setup the endpoint peer (Wireguard server) with Allowed IP 0.0.0.0/0 to allow all the packets to be passed into the VPN tunnel. I’m hoping to use per policy routing to isolate which hosts will send internet-bound packets through the VPN.
    2. Setup the local peer with 10.0.10.2/24 and disable routing to allow the opnsense server to route VPN subnet packets correctly. (see questions after my configuration description). This appears to create a 10.0.10.2/32 route and a 10.0.10.0/24 route on the opnsense server.

On wireguard server:
    1. Create the HOME LAN peer configuration.
        1.1. Allowed IP is set to {10.0.10.2/32, 10.0.0.1/24, 10.0.1.1/24) so all packets intended for the Home LAN is routed correctly to the HOME LAN (and allowed from the Home LAN). This should work for both site-to-site and site-to-internet (since NAT is occurring on the wireguard server).
    2. Create the Remote LAN peer configuration.
        2.1. Allowed IP is set to {10.0.10.3/32, 10.0.2.1/24) so all packets intended for the Remote LAN is routed correctly to the Remote LAN (and allowed from the Remote LAN). Same concept as the HOME LAN.
    3. Create the roadwarrior peer configuration.
        3.1. Allowed IP is set to { 10.0.10.4/32) since there are no hosts behind the roadwarrior that need to be routed.
    4. Create the Server LAN peer
        4.1. Nothing special here except for the NAT rule to allow internet access.

On HOME opnserver:
    1. Assign the wireguard interface without an IP address because it will automatically pick it up from the local peer.
        1.1. Perform stop/start on the VPN to ensure the interface picks up the IP.
    2. Create the gateway using remote IP (10.0.10.1) and monitor IP (10.0.10.1).
        2.1. Perform stop/start on the VPN to ensure the interface and gateway are up to date.
    3. Create floating rule to allow all my Home LAN hosts to communicate with the remote LAN network (assuming I do the same on the remote LAN – still pending).
         Rules: Floating
         Action: Pass
         Quick: True (aka first match)
         Direction: Inbound
         Interfaces: Both LAN interfaces {10.0.0.1/24, 10.0.1.1/24)
         Protocol: any
         Source: any
         Destination {10.0.2.0/24, 10.0.10.0/24}
         Gateway: Wireguard Gateway (Wireguard server IP)
    4. Create floating rule to force specific Home LAN hosts to the use the Wireguard server internet connection (home services should not be directed to Wireguard VPN).
         Rules: Floating
         Action: Pass
         Quick: True (aka first match)
         Direction: Inbound
         Interfaces: Both LAN interfaces {10.0.0.1/24, 10.0.1.1/24)
         Protocol: any
         Source: 10.0.1.50 (example LAN host)
         Destination !{10.0.0.0/24, 10.0.1.0/24}
         Gateway: Wireguard Gateway (Wireguard server IP)
    5. Create a gateway rule since the Wireguard interface does not have a fixed IP (from selective routing guide step #9 and github issue #5329).
         Rules: Floating
         Action: Pass
         Quick: False (aka last match)
         Direction: Outbound
         Interfaces: None (which sets it to all?)
         Protocol: any
         Source: WG interface address (which resolves to 10.0.10.2/32)
         Destination !WG interface net (which resolves to !10.0.10.2/24)
         Gateway: Wireguard Gateway (Wireguard server IP)

Everything seems to be working correctly except for a few questions/issues below.
I might have opened up some vulnerabilities so any guidance would be appreciated.

Few questions:
    1. Step 4 above: For all other LAN hosts that can access the Remote LAN and/or Roadwarrior (but continue to access the internet from the Home WAN), I used a rule to force all VPN networks into the VPN gateway and set the remote peer to Allowed IP to 0.0.0.0/0. This seems like it provides more granular control than setting the remote peer Allowed IP to the specific Remote LAN network (in case it grows in the future). There was also the behaviour that opnsense was assigning an IP for each additional subnet that I wanted routed into the VPN even through I did not want an IP from the subnet to be associated to opnsense (e.g. adding 10.0.2.0/24 added 10.0.2.0 to opnsense even though I don’t control that subnet since its on the Remote LAN). Is there unforeseen risk with this approach?
    2. Step 5 above: For LAN hosts that should fully use the VPN gateway, instead of creating a rule to direct non-RFC1918 networks (except LAN networks) to the VPN gateway, I choose to build the rule to direct all VPN networks to be VPN gateway. Since I need to access some services on the Home LAN network, this seems to be a better solution. Is there unforeseen risk with this approach?
    3. Other: I cannot ping my VPN local peer endpoint (10.0.10.2) from the opnsense server (essentially the local VPN gateway). I can ping my other LAN interfaces (10.0.0.1, 10.0.1.1). Am I missing a rule or setting? Note that I can ping the local peer endpoint (10.0.10.2) from the Remote LAN endpoint and from Home LAN hosts.
    4. I’m still trying to find a way to route all Unbound traffic to the VPN. I tried setting the Outgoing Network interfaces to the VPN interface but it did not work (help states that it only works for statically configured interfaces). Is there a different recommended method?

Thanks in advance,

3

Virtual private networks / Wireguard Selective Routing Instructions - Question

« on: February 18, 2023, 11:16:12 pm »

Hi,
I'm following the wireguard selective routing instructions on the docs.opnsense.org website.
Step 9 has me confused; as in, I would like to understand the purpose of it.

Step 2: Configure local peer instructs the Tunnel Address to be /32. This makes sense in that a specific IP is assigned to the VPN local peer (e.g. 10.0.0.2/32) and routing is disabled (assuming that the firewall rules will take care of it).

Step 2 and 6: Creates a gateway on the VPN subnet. (e.g. 10.0.0.1/32)

I performed all the steps 1-8.
At this point, my opnsense server can ping the gateway (10.0.0.1/32) but cannot ping a remote peer (10.0.0.3/32). A local LAN host can ping the gateway (10.0.0.1/32) and a remote peer (10.0.0.2/32). The remote peer can ping my defined gateway (10.0.01/32) and a host in my LAN (192.168.0.x) but cannot ping my local peer (10.0.0.2/32).

Step 9: Configure routing instructions has me confused.
It states that all outbound packets originating from the VPN address (10.0.0.2/32) with an destination of the VPN network should be directed to the VPN gateway (e.g. 10.0.0.1/32).

Couple of questions:
1. Where did we define the VPN network being used in Step 9? Since we specified the VPN local peer in step 2 to be 10.0.0.2/32 and the interface picks up the IP and subnet from the VPN local peer, wouldn't the VPN network be 10.0.0.2/32?
If yes, why are routing a packet from 10.0.0.2/32 to 10.0.0.2/32 to a gateway in the VPN tunnel?
If no (and the VPN network is identified correctly e.g 10.0.0.2/24), is this rule for allowing the firewall and NAT'd clients to access the VPN?

Adding the routing rule in step 9 did not make a difference to my ping issues prior to step 9.

2.  Assuming that I'm not performing NAT (other peers can route packets for my subnet back through the VPN tunnel), I would not create a NAT rule (step 10). Does step 9 provide any purpose/value if I'm not creating the NAT rule (step 10)?

Thanks,

4

22.1 Legacy Series / [Solved] Re: PPPoE over VLAN through managed switch doesn't work

« on: April 07, 2022, 12:58:25 am »

Tried it and it still didn't work.
OPNsense untagged --> port based VLAN X in whatever switch infrastructure (need not even be 35) --> still port based egress (untagged) --> modem (adds VLAN 35)

But I found the solution.
I decided to just try changing different port settings on the modem (didn't expect any effect) and it worked when I forced the speed (100Mb/s) and duplex setting (both).
No idea why since I never had an issue with the switches or the modem auto-negotiating before (except when connected to each other obviously even though it appears to auto-negotiate correctly based on the switch and modem status page).
Hope this will help someone in the future if the encounter this weird behavior.
Any idea how I can update the thread as solved?

5

22.1 Legacy Series / Re: PPPoE over VLAN through managed switch doesn't work (but direct connection does)

« on: April 06, 2022, 11:05:20 pm »

I tried it as the second attempt (2a) with the same result (no response).
OpnSense (untagged) -> (PVID 35) switch (VLAN 35) -> modem -> ISP

I know a direct connection works for both scenarios below:
1. Opnsense sending the packet as VLAN 35 with the modem passing the packet untouched
2. OpnSense sending the packet untagged with the modem retagging it as VLAN 35.
 
Whenever I include any switch in the path, it fails.
1. Passthrough VLAN 35 from OpnSense to modem.
2. Take VLAN 35 packet from OpnSense and clear the tag before sending to the modem (and let the modem tag it for the ISP).
3. Take untagged packet from OpnSense and tag it as VLAN 35 before sending it to the modem.

I'm out of ideas so please keep any suggestions coming.
I'm will to try them all.

Maybe I will try sending an untagged packet from OpnSense to the switch to the modem.
Problem is that this will not help me traverse the packet through a trunk.
I need the packet tagged when it leaves OpnSense.

6

22.1 Legacy Series / Re: PPPoE over VLAN through managed switch doesn't work (but direct connection does)

« on: April 06, 2022, 09:37:40 pm »

In the switch, I can apply ports to the VLANs as tagged or untagged. I applied both ports as tagged to VLAN 35.
Did not work.

I also took your suggestion to tag all the VLANs to the port (essentially making it a trunk) and experienced the same timeout failure.
OPNsense (tagged) VLAN 35 --> Trunk Port in Switch (all VLANs tagged) --> Trunk Port on Switch (all VLANs tagged) --> Modem

Any other ideas would be appreciated.

Thanks,

7

22.1 Legacy Series / PPPoE over VLAN through managed switch doesn't work (but direct connection does)

« on: April 06, 2022, 03:52:40 pm »

Hi,
Happy OpnSense user here.
I've run into an issue (which is probably not a OpnSense issue) but I thought I would ask in case I missed a setting or someone has resolved this issue in the past.

Background:
My OpnSense is configured to initiate a PPPoE connection through an interface (igb1) and it works perfectly.
OpnSense (untagged) -> Modem (VLAN 35) -> ISP (this works)

Issue:
I want to eventually separate the location of the modem and OpnSense using a trunk to initiate the PPPoE connection.
So I tested as follows:
1. Ensure modem can leave VLAN untouched by tagging the packets in OpnSense. (this works)
2. Pass the tagged packets though a managed switch to ensure the switch si not creating issues. (I'm failing here)
3. Send the tagged packets through a trunk to another switch where the modem will reside.

Step 1:
To ensure that the modem can support leaving the VLAN untouched, I switched the PPPoE connection to use VLAN 35, change my modem setting to leave the VLAN unchanged and everything appears to work correctly
OpnSense (VLAN 35) -> Modem (VLAN untouched) -> ISP (this works)

Based on the above, it appears that the PPPoE connection seems to work well with untagged or tagged (35) packets when OpnSense and the modem are directly connected.

Step 2:
I tried sending OpnSense (VLAN 35) -> (VLAN 35) switch (VLAN 35) -> modem (VLAN untouched) -> ISP but I keep getting connection timed out.
Both ports on switch are members of VLAN 35; no other ports are members of VLAN 35.

Step 2a:
Then I tried OpnSense (untagged) -> (PVID 35) switch (VLAN 35) -> modem -> ISP but I also keep getting connection timed out.
No other ports are members of VLAN 35.

Step 2c:
I thought maybe the switch (Brocade TurboIron) was doing something odd (or had a bug) so I tried another brand (Fastpath) and got the same timeout results.

Is there a setting that I'm missing in OpnSense or the managed switches to allow PPPoE over VLAN to work when going through a managed switch?

Thanks in advance,
Sal