Route one IP over VPN?

Started by conanTheRouter, June 25, 2018, 12:02:22 AM

Previous topic - Next topic
June 25, 2018, 12:02:22 AM Last Edit: August 02, 2018, 12:25:41 AM by conanTheRouter
Alright! Figured we could sort https://forum.opnsense.org/index.php?topic=4979.0 guide out so that it actually works. I have formatted it a bit and made some small changes to it. Hope this can be a discussion on solving the issues to get this working.

End state:

  • User can add client IP to alias list
  • Clients are routed through VPN
  • If VPN goes down, no Internet access to clients in alias list
  • All other clients are not routed through VPN
  • If VPN goes down, clients not listen in alias list still have Internet access

My current machine is:
OPNsense 18.1.10-amd64
FreeBSD 11.1-RELEASE-p10
OpenSSL 1.0.2o 27 Mar 2018


Step 1:
Download your certificate from your VPN provider. You should as a minimum get a certificate, password and username.

Step 2:
Navigate to System > Trust > Authorities, "Add or import CA"
- Descriptive name: VPNCA (I use mullvad VPN)
- Certificate data: (paste the contents of your CA.crt file here)
- Certificate Private key: (paste the contents of your user.key file here) (if you have any!)
- Serial for next Certificate : None

SAVE

Step 3:
Navigate to VPN > OpenVPN > Clients, "add client"
Edit the following settings: (some may differ depending on your VPN provider)

- Server Mode: Peer to Peer (SSL/TLS)
- Protocol: UDP (check your ovpn file)
- Device Mode: tun (check your ovpn file)
- Interface: (Your WAN interface)
- Local port: 443 (check your ovpn file)
- Server Host or Address: 123.45.67.890 (check your ovpn file)
- Server Port: 443 (check your ovpn file)
- Server host name resolution: Ticked
- Description: "Name of your VPN Provider"

User Authentication Settings
- Username/pass: enter your username
- Renegotiate time: leave empty

Cryptographic Settings:

- TLS Authentication: unticked
- Peer Certificate Authority: Select "VPNCA" or whatever you called the description in step 2.
- Client Certificate: None (Username and password required)
- Encryption: Check your VPN Provider, mine was AES-256-CBC (256 bit key, 128 bit lock)
- Auth Digest Algorithm: SHA1(160-bit) (Check with your VPN Provider)
- Disable IPV6: Ticked
- Don't add/remove routes: ticked
- Advance Configuration: "Paste the below data into the field"
   
  persist-key;
  persist-tun;
  remote-cert-tls server;
  reneg-sec 0;
  sndbuf 524288;
  rcvbuf 524288;
  fast-io;
 
- Verbosity level: 3

SAVE

Step 5:
Check to see if your VPN connection is online,

Navigate to VPN > OpenVPN >  Connection Status

You should see "Status" UP with your "Remote Host" IP address supplied from the VPN Provider

Now check the log file for the words "Initialization Sequence Completed"

If you see "openvpn[36641]: MANAGEMENT: Client disconnected". Thats okey, thats your client checking the status.

Step 6:
Navigate to Interfaces > Assignments
- Select the pull down menu under "new interface" and make sure the "ovpnc1" option is selected
- Click the orange "+" button
- Tick Enable Interface and Save
- Description = VPN (note this is a "Virtual" interface, its not referenced to an physical Ethernet port)
- IPV4 Configuration type = DHCP
- IPV6 = None
- Note: Leave all other settings as default (empty/unticked)

Step 7:
Navigate to Firewall > Aliases > View
- Add a new Alias
- Name: VPNTraffic
- Description : VPNTraffic
- Type: Host(s)
- First entry: 192.168.X.X

!!!WARNING!!! Dont dodge this step, even if you think you know what im doing, the whole point of making aliases is important, and it wont work without them.

SAVE

Step 8:
Navigate to Firewall > NAT > Outbound

- Select "Manual outbound NAT generation" (Leave the default generated WAN rules AS IS)
- Add a new rule

Rule 1.
(if not autogenerated)
- Interface: WAN
- TCP/IP Version: IPv4
- Protocol: any
- Source address: Singel host or Network -> 127.0.0.0/8
- Destination port: other -> 500
- Static port: ticked
- Translation / target: Interface address
- Description: "Rule for ISAKMP - localhost to WAN"

Rule 2.
(if not autogenerated)
- Interface: WAN
- TCP/IP Version: IPv4
- Protocol: any
- Translation / target: Interface address
- Source address: Singel host or Network -> 127.0.0.0/8
- Description: "Rule for - localhost to WAN"

Rule 3.
(if not autogenerated)
- Interface: WAN
- TCP/IP Version: IPv4
- Protocol: any
- Translation / target: Interface address
- Source address: Singel host or Network -> 192.168.1.0/24
- Destination port: other -> 500
- Static port: ticked
- Description: "Rule for ISAKMP - LAN to WAN"

Rule 4.
(if not autogenerated)
- Interface: WAN
- TCP/IP Version: IPv4
- Protocol: any
- Translation / target: Interface address
- Source address: Singel host or Network -> 192.168.1.0/24
- Description: "Rule - LAN to WAN"

Rule 5.
- Interface: VPN (The one you created in Step 6)
- Source: VPNTraffic ( The alias you created in Step 7)
- Translation / target: Interface Address (as in, just select "Interface address" from the dropdown menu)
NOTE: Leave ALL other options as default/any

Rule 6. (Same as Rule 5, but....)
- Destination port: 500 (Select "Other" from dropdown menu and enter 500 in the field)
- Static Port: Ticked
NOTE: Leave ALL other options as default/any

Rule 7.
- Interface: VPN (The one you created in Step 6)
- Source: Single host or network, 127.0.0.0 / 8
- Translation / target: Interface Address (as in, just select "Interface address" from the dropdown menu)

NOTE: Leave ALL other options as default/any
NOTE: Make sure the above rules "are above" your auto generated WAN outbound rules when looking at the entire list from top to bottom.

APPLY SETTING

Step 9.
Navigate to Firewall > Rules > LAN

NOTE: The order of Rules from top to bottom on this page matter:
Starting at the top, you should have the "Anti-Lockout Rule"
Next, start adding rules as follows:

Rule 1. (The Rule to pass selected clients traffic out via the VPN)
- Interface: LAN
- TCP/IP Version: IPv4
- Source: VPNTraffic (Alias)
- Gateway: VPN_DHCP (ie, the auto-generated VPN Gateway option)
- Advance options: Set local tag: PIA_NO_WAN_EGRESS

Rule 2. (Copy the above rule)(Killswitch if OpenVPN client goes down)
- Advance options: Set local tag: PIA_NO_WAN_EGRESS


Rule 2. (Pass all other traffice out via the defaul gateway "WAN")

- Interface: LAN
- TCP/IP Version: IPv4
- Source: Any
- Gateway: WAN_PPPoE (ie, the auto-generated WAN Gateway, the name might be different depending
on your WAN connection method)

Apply settings

Step 10.
Navigate to Firewall > Rules > floating
Add new Rule

- Action: Block
- Interface: WAN
- Direction: out
- Direction: any
- Match local tag: PIA_NO_WAN_EGRESS



Todo:

  • Port forward through VPN

I have called my VPN alias BlackNET and this is my NAT and LAN rules.

I have tried changing rule order, disable/enable different rules, tried changing gateways but I'm stuck...

Alright. The only thing left is the "killswitch". If the OpenVPN client goes down, no internet access should be allowed to WAN for those specific IPs in the alias list.

I think I manage to get the killswitch in place.

I let some time pass, doing a little wait-and-see to see if this method works and works reliably over the course of several days.

How is this method doing?    Does it all work now?

The kill switch does not work for me.
I set logging on both rule 1 and 2 (step 9, firewall rules) and I can see that I get a match on the first one from VPNTraffic clients no matter the state of the VPN connection.
It seems that the rule match even if the auto generated gateway does not exist, as a result of the VPN being down, and as a fallback sets the default gateway.

I'm running 18.1.11.

July 17, 2018, 02:32:22 AM #6 Last Edit: July 17, 2018, 02:37:56 AM by ou812
Ok, solved the kill switch problem.
The error in the guide is to create Rule 1 and Rule 2 on the LAN interface. Forget Rule 2 and add the PIA_NO_WAN_EGRESS tag already in Rule 1 and it works as intended. (18.1.11) :)

The floating rule on the WAN interface could by the way be set to Direction: out instead of any. No functional change but a more exact rule.

Also, on the NAT setup, if you check the Hybrid mode instead of Manual you get the auto configured NAT rules for free. I found that better.

Quote from: ThePOO on July 10, 2018, 05:38:15 AM
I let some time pass, doing a little wait-and-see to see if this method works and works reliably over the course of several days.

How is this method doing?    Does it all work now?

Yes is seems to work perfect =) Even in 18.1.12

conanTheRouter:    Can you please edit the modifications, presented by ou812, into your configuration?

I will be implementing this configuration, with ou812's modifications on an 18.7rc2 box this Thursday, or Friday, and give it a real run for its money.     YAY! 

Quote from: ThePOO on July 23, 2018, 08:45:32 AM
conanTheRouter:    Can you please edit the modifications, presented by ou812, into your configuration?

I will be implementing this configuration, with ou812's modifications on an 18.7rc2 box this Thursday, or Friday, and give it a real run for its money.     YAY!

Alright I have made the changes to the guide! I have marked the changes with bold lettering. Give the guide some feedback once you have tested it!

ps. I havent tested these changes myself yet, so I hope ou812 has it right  ;D

In Step 8, Rule 6, shouldn't that read "Same as rule 5" instead of "Same as rule 1"?

Quote from: Uica on July 31, 2018, 09:44:26 PM
In Step 8, Rule 6, shouldn't that read "Same as rule 5" instead of "Same as rule 1"?

Yes, that is correct. It should be "same as rule 5".

Also as I mentioned in a previous post, Step 8 rule 1-4 are auto generated if you select hybrid mode.

Another thing is that someone might be able to explain to me is the significance of rule 7. 127.0.0.0/8 to VPN? I don't see a reason for this if only the VPNTraffic hosts should send traffic over the VPN. Why mixing in firewall local addresses?


Quote from: Uica on July 31, 2018, 09:44:26 PM
In Step 8, Rule 6, shouldn't that read "Same as rule 5" instead of "Same as rule 1"?

Good catch! Fixed :D

The killswitch is no longer working for me in 18.7.  Does anyone have it working or a fix?

Quote from: mow4cash on October 12, 2018, 04:02:13 AM
The killswitch is no longer working for me in 18.7.  Does anyone have it working or a fix?

I can see if I can test and see if I can fix it.