welw | About_me Blog WebAssembly

I would like to set up one of my vpn clients (specific certificate), to always get the same ip address as client, so I can configure routing tables. I host OpenVPN.

To assign a static IP address in OpenVPN for a specific client using their certificate, you need to modify your server configuration file. Here’s a concise guide:

  1. Enable Client Certificate Common Name (CN) usage in the server configuration:

    • In your server.conf, add or ensure: plaintext client-cert-not-required username-as-common-name

  2. Create a script to assign static IPs:

    • In the same directory as your server.conf, create a file named ccd/<client-CN> where <client-CN> is the common name of the client's certificate.
    • Add the following line to that file: plaintext ifconfig-push <static-ip> <netmask>
    • Replace <static-ip> and <netmask> with the desired IP address and netmask for this client. For example: plaintext ifconfig-push 10.8.0.5 255.255.255.0

  3. Enable Client Config Directory:

    • Ensure the following line is in your server.conf: plaintext client-config-dir ccd

  4. Restart OpenVPN server:

    • Use the appropriate command to restart your OpenVPN server, such as: bash sudo systemctl restart openvpn@server
    • Or, depending on your system: bash sudo service openvpn restart

This setup will ensure that whenever the specified client connects, they receive the same static IP address, allowing you to configure routing tables accordingly. Make sure the CN in the certificate matches exactly what you use in the ccd folder.

VPNs typically do not guarantee a static IP address for clients. However, some VPN providers offer static IP services. Ensure your provider supports this feature. If they do, contact them to request a static IP assigned to your certificate. For configuring routing tables, consult your provider's documentation on how to use the static IP for routing rules.

Add route to 172.30.x.x via 192.168.10.100 on freebsd

To add a route to 172.30.x.x via 192.168.10.100 on FreeBSD, you can use the route command. Here is how:

sh sudo route add 172.30.0.0/16 192.168.10.100

This adds a route to the 172.30.0.0/16 subnet via the gateway 192.168.10.100.

If you want this route to persist after reboots, you can add it to the /etc/rc.conf file or the /etc/rc.conf.d/routing file:

  1. Edit /etc/rc.conf or /etc/rc.conf.d/routing:

    • You can use an editor like vi or nano. For example: sh nano /etc/rc.conf.d/routing

  2. Add the route:

    • Add the following line: sh static_routes="my_route" route_my_route="172.30.0.0/16 192.168.10.100"

  3. Save and exit:

  4. Activate the route immediately:

    • Run the command: sh sudo service routing start

This ensures that the route is added every time the system boots.

I can ssh to my 192.168.10.100 machine, which is a router for 172.30.x.x/12 subnet. I added route in freebsd. I would like to confirm that the bsd box indeed routes 172.30.x.x via 192.168.10.100 and then setup appropriate routing rules on pi (192.168.10.100 / 172.30.0.2).

Sure, let's confirm the route on your FreeBSD box and then set up the appropriate routing rules on your Raspberry Pi (acting as the router).

Confirm Route on FreeBSD

  1. Check the routing table:
    • Use the following command to see the current routing table: sh netstat -rnf inet
    • Look for an entry like: 172.30.0.0/12 192.168.10.100 UGS 0 24 vtnet0

Set Up Routing Rules on Raspberry Pi (Router)

Since your Raspberry Pi is acting as a router for the 172.30.x.x/12 subnet, you need to ensure it has the correct routing to forward traffic from the FreeBSD box (192.168.10.xx) to the 172.30.x.x/12 subnet.

  1. Ensure IP forwarding is enabled:

    • Check if IP forwarding is enabled: sh sysctl net.ipv4.ip_forward
    • If it returns 0, enable it by running: sh sudo sysctl -w net.ipv4.ip_forward=1
    • To make the change persistent, edit /etc/sysctl.conf and add or uncomment: sh net.ipv4.ip_forward=1

  2. Set up NAT for outgoing traffic:

    • If the FreeBSD box needs to access the internet through your Raspberry Pi, set up NAT masquerading: sh sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    • Replace eth0 with the appropriate interface for your Raspberry Pi's internet connection.

  3. Add a static route for traffic from FreeBSD to 172.30.x.x/12:

    • Add the route on the Raspberry Pi: sh sudo route add -net 172.30.0.0 netmask 255.240.0.0 gw 192.168.10.100

  4. Verify the routing table on Raspberry Pi:

    • Use the following command to check the routing table: sh netstat -rn
    • Look for an entry like: 172.30.0.0 * 255.240.0.0 UG 0 0 eth0

  5. Make routes persistent (optional):

    • To make the route persistent across reboots, add it to /etc/network/interfaces or /etc/rc.local:
      • Edit /etc/network/interfaces: sh post-up route add -net 172.30.0.0 netmask 255.240.0.0 gw 192.168.10.100
      • Or, edit /etc/rc.local (if it exists): sh route add -net 172.30.0.0 netmask 255.240.0.0 gw 192.168.10.100

  6. Check firewall rules (if applicable):

    • Ensure that the Raspberry Pi's firewall rules allow traffic to flow between the 192.168.10.x and 172.30.x.x subnets.

By following these steps, you should be able to verify and set up the routing correctly on both your FreeBSD box and the Raspberry Pi.

Clients connected to the pi have addressess 172.30.x.x/12. Packets are coming from interaface tun0 acting as openvpn client.

I can either set up openvpn server and connect to it as client, or route through the client connected interface. Which solution is best and why?

Given your setup, where the Raspberry Pi (RPi) acts as both a router and an OpenVPN client, and the clients connected to the RPi have addresses in the 172.30.x.x/12 subnet, you have two primary options:

  1. Set up an OpenVPN server on the RPi and connect from the FreeBSD box:
  2. Route traffic from the FreeBSD box through the OpenVPN client interface (tun0) on the RPi:

Option 1: OpenVPN Server on RPi

Pros: - Separation of Concerns: The RPi handles all VPN-related tasks, while the FreeBSD box focuses on routing. - Scalability: Easily manage multiple clients directly connected to the RPi. - Security: Centralized VPN management and security policies on the RPi.

Cons: - Complexity: Requires setting up both OpenVPN client and server on the RPi. - Resource Usage: The RPi must handle both incoming client connections and OpenVPN client traffic.

Option 2: Route Through tun0 on RPi

Pros: - Simplicity: The FreeBSD box directly uses the RPi's VPN connection. - Efficiency: Reduces the number of components and connections.

Cons: - Dependency: The FreeBSD box becomes dependent on the RPi's VPN connection. If the RPi disconnects, the FreeBSD box loses its VPN connectivity. - Limited Control: The FreeBSD box has less control over VPN-specific settings and policies.

Recommended Solution

Option 2: Route Through tun0 on RPi is generally the better choice for your scenario due to simplicity and efficiency. Here’s how you can configure it:

Configure Routing on FreeBSD Box

  1. Add a Static Route:

    • Add a route to send traffic destined for 172.30.x.x/12 through the RPi's tun0 interface: sh sudo route add 172.30.0.0/12 192.168.10.100

  2. Persistent Route:

    • To make the route persistent, add it to the /etc/rc.conf file: sh static_routes="my_route" route_my_route="172.30.0.0/12 192.168.10.100"

Ensure RPi Routes Properly

  1. Enable IP Forwarding:

    • Ensure IP forwarding is enabled on the RPi: sh sudo sysctl -w net.ipv4.ip_forward=1

  2. NAT Configuration:

    • Set up NAT to allow traffic from the 172.30.x.x/12 subnet to the internet: sh sudo iptables -t nat -A POSTROUTING -s 172.30.0.0/12 -o eth0 -j MASQUERADE
    • Save the iptables rules to persist across reboots: sh sudo sh -c "iptables-save > /etc/iptables/rules.v4"
    • Ensure the iptables-persistent service is enabled: sh sudo systemctl enable netfilter-persistent.service

  3. IP Tables Rule Persistence:

    • Create /etc/iptables/rules.v4 if it doesn't exist and add the MASQUERADE rule.

  4. Routing Table on RPi:

    • Ensure that the RPi's routing table allows traffic from the VPN (tun0) to pass through: sh ip route show
    • You should have a default route via the RPi’s internet interface and a route specific to the 172.30.x.x/12 subnet via the VPN interface.

Verify the Setup

  1. Ping Test:

    • From the FreeBSD box, ping a device within the 172.30.x.x/12 subnet to ensure traffic routes correctly: sh ping 172.30.0.2

  2. Traceroute:

    • Use traceroute to verify the path: sh traceroute 172.30.0.2

This setup ensures that the FreeBSD box efficiently routes traffic through the RPi's OpenVPN connection without adding unnecessary complexity.

It's still not routing. tracepath shows * *.

Let's diagnose and fix the routing issue step-by-step. Given your setup, where the Raspberry Pi (RPi) acts as an OpenVPN client and the FreeBSD boxroutes through the RPi's tun0 interface, we need to ensure several configurations are correct.

Steps to Diagnose and Fix

1. Verify OpenVPN Connection on RPi

First, ensure that the RPi is successfully connected to the OpenVPN server and has an IP address on the tun0 interface.

  1. Check OpenVPN Status: sh sudo systemctl status openvpn@client

    • Replace client with the actual name of your OpenVPN configuration file.

  2. Check tun0 Interface: sh ip addr show tun0

    • You should see an IP address assigned to tun0.

2. Ensure IP Forwarding on RPi

  1. Enable IP Forwarding: sh sudo sysctl -w net.ipv4.ip_forward=1

  2. Persist IP Forwarding:

    • Add the following line to /etc/sysctl.conf: sh net.ipv4.ip_forward=1

3. Configure NAT on RPi

Since the RPi is acting as a NAT gateway for the 172.30.x.x/12 subnet, you need to set up the NAT rules correctly.

  1. Flush Existing NAT Rules: sh sudo iptables -t nat -F

  2. Set Up NAT Masquerading: sh sudo iptables -t nat -A POSTROUTING -s 172.30.0.0/12 -o eth0 -j MASQUERADE

    • Replace eth0 with the correct interface name if different.

  3. Save iptables Rules: sh sudo sh -c "iptables-save > /etc/iptables/rules.v4"

  4. Enable iptables-persistent: sh sudo ufw disable # Disable ufw if it conflicts with iptables-persistent sudo systemctl enable netfilter-persistent.service sudo systemctl start netfilter-persistent.service

4. Configure Routing on RPi

Ensure that the RPi has a proper route for the 172.30.x.x/12 subnet to its own LAN interface and that traffic destined for the OpenVPN remote network is routed through tun0.

  1. Check Current Routes: sh ip route show

  2. Add Route for 172.30.x.x/12: If the route is not present, add it: sh sudo ip route add 172.30.0.0/12 dev eth1

    • Replace eth1 with the correct LAN interface name.

  3. Default Route via Internet Interface: Ensure you have a default route via the internet-facing interface: sh ip route show | grep default

    • If not, add it: sh sudo ip route add default via <internet-gateway-ip> dev eth0
    • Replace <internet-gateway-ip> with your actual internet gateway IP.

  4. Route VPN Traffic: Ensure that traffic destined for the OpenVPN remote network is routed through tun0: sh sudo ip route add <openvpn-remote-network> via <tun0-ip> dev tun0

    • Replace <openvpn-remote-network> with the remote network IP range.
    • Replace <tun0-ip> with the IP address assigned to tun0 on the RPi.

5. Configure Routes on FreeBSD

Ensure that FreeBSD is correctly routing traffic through the RPi's tun0 interface.

  1. Add Static Route: sh sudo route add 172.30.0.0/12 192.168.10.100

  2. Persistent Route:

    • Add the following to /etc/rc.conf: sh static_routes="my_route" route_my_route="172.30.0.0/12 -gateway 192.168.10.100 -iface vtnet0"
    • Replace vtnet0 with the correct interface name on your FreeBSD box.

6. Verify Connectivity

  1. Ping the Client:

    • From FreeBSD, ping a client inside the 172.30.x.x/12 subnet: sh ping 172.30.0.2

  2. Tracepath:

    • Use tracepath to verify the route: sh tracepath 172.30.0.2

7. Debugging

If the problem persists, perform some debugging:

  1. Check IP Tables on RPi: sh sudo iptables -t nat -L -n -v

  2. Check Firewall Rules:

    • Ensure there are no conflicting firewall rules on the RPi: sh sudo ufw status

  3. Verify Network Interfaces:

    • Double-check the correct interface names and IP addresses: sh ip addr show

  4. Check Logs:

    • Check OpenVPN logs on the RPi for any errors: sh sudo tail -f /var/log/openvpn/client.log
    • Ensure there are no errors indicating issues with routing or NAT.

Example Commands

Here’s a quick checklist:

On RPi:

  1. OpenVPN Status: sh sudo systemctl status openvpn@client

  2. tun0 Interface IP: sh ip addr show tun0

  3. IP Forwarding: sh sudo sysctl -w net.ipv4.ip_forward=1

  4. NAT Rules: sh sudo iptables -t nat -A POSTROUTING -s 172.30.0.0/12 -o eth0 -j MASQUERADE

  5. Save iptables: sh sudo sh -c "iptables-save > /etc/iptables/rules.v4"

  6. Routes: sh sudo ip route add 172.30.0.0/12 dev eth1 sudo ip route add default via <internet-gateway-ip> dev eth0

On FreeBSD:

  1. Add Static Route: sh sudo route add 172.30.0.0/12 192.168.10.100

  2. Persistent Route:

    • Add to /etc/rc.conf: sh static_routes="my_route" route_my_route="172.30.0.0/12 -gateway 192.168.10.100 -iface vtnet0"

  3. Ping Test: sh ping 172.30.0.2

  4. Tracepath: sh tracepath 172.30.0.2

By following these detailed steps, you should be able to diagnose and resolve the routing issue. If problems continue, consider checking for any specific firewall rules or network configurations that might be interfering.

I believe something is wrong with nat on bsd:

PING 192.168.10.100 (192.168.10.100) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=23.3 ms (DIFFERENT ADDRESS!)

64 bytes from 10.0.0.2: icmpseq=3 ttl=63 time=25.1 ms (DIFFERENT ADDRESS!) 64 bytes from 10.0.0.2: icmpseq=4 ttl=63 time=23.1 ms (DIFFERENT ADDRESS!) 64 bytes from 10.0.0.2: icmp_seq=5 ttl=63 time=22.5 ms (DIFFERENT ADDRESS!)

Given the output of your ping command, it seems that the replies are coming from a different address (10.0.0.2 instead of 192.168.10.100). This indicates that the NAT configuration on your FreeBSD box might not be set up correctly. Let's go through the necessary steps to ensure NAT is configured properly.

Ensure NAT is Configured on FreeBSD

FreeBSD uses pf (Packet Filter) for firewall and NAT functionality. Below are the steps to configure NAT using pf.

1. Enable pf Service

Ensure pf is enabled in /etc/rc.conf:

sh echo "pf_enable=\"YES\"" | sudo tee -a /etc/rc.conf echo "pf_rules=\"/etc/pf.rules\"" | sudo tee -a /etc/rc.conf

2. Configure pf with NAT Rules

Edit the /etc/pf.rules file to include NAT rules:

sh sudo nano /etc/pf.rules

Add the following rules:

```plaintext

Define interfaces

extif="vtnet0" # External interface (connected to RPi) intif="vtnet1" # Internal interface (connected to local network if needed)

NAT rule to route traffic from FreeBSD through RPi's tun0

nat on $extif from 172.30.0.0/12 to any -> ($extif)

Allow traffic between FreeBSD and RPi

pass out on $extif from 172.30.0.0/12 to any keep state pass in on $extif from any to 172.30.0.0/12 keep state ```

Replace vtnet0 with your actual external interface name (the one connected to the RPi).

3. Restart pf Service

Reload the pf configuration to apply the changes:

sh sudo pfctl -f /etc/pf.rules sudo service pf restart

4. Verify pf Configuration

Check the status of pf to ensure the NAT rule is active:

sh sudo pfctl -s nat

You should see a NAT rule similar to:

match out on vtnet0 inet from 172.30.0.0/12 to any nat-to (vtnet0)

5. Configure Static Route

Ensure the static route is correctly configured to route traffic through the RPi:

sh sudo route add 172.30.0.0/12 192.168.10.100

And make it persistent by adding to /etc/rc.conf:

sh echo "static_routes=\"my_route\"" | sudo tee -a /etc/rc.conf echo "route_my_route=\"172.30.0.0/12 -gateway 192.168.10.100\"" | sudo tee -a /etc/rc.conf

Verify the Setup

  1. Check Routing Table: sh netstat -rnf inet

    Ensure you have an entry like: 172.30.0.0/12 192.168.10.100 UGS 0 0 vtnet0

  2. Ping Client in 172.30.x.x/12: sh ping 172.30.0.2

    Ensure the replies come from 192.168.10.100 or the correct tun0 interface on the RPi.

  3. Tracepath: sh tracepath 172.30.0.2

Example pf Rules

Here is a more complete example of /etc/pf.rules:

```plaintext

Macros

ext_if="vtnet0" # External interface (connected to RPi)

Options

set skip on lo0 set block-policy return set loginterface egress

NAT rule

nat on $extif from 172.30.0.0/12 to any -> ($extif)

Default deny, allow specific traffic

block in all pass out all keep state

Allow SSH traffic (if needed)

pass in on $extif proto tcp from any to ($extif) port ssh keep state

Allow traffic between FreeBSD and RPi

pass out on $extif from 172.30.0.0/12 to any keep state pass in on $extif from any to 172.30.0.0/12 keep state ```

Final Steps

  1. Check pf Logs: sh sudo pfctl -t sshguard -T show sudo dmesg | grep pf

  2. Debugging:

    • Use tcpdump on the RPi to capture packets and ensure they are being sent and received correctly: sh sudo tcpdump -i tun0

By following these steps, you should be able to configure NAT correctly on your FreeBSD box and ensure proper routing through the RPi's tun0 interface. If issues persist, double-check the interface names and ensure there are no conflicting firewall rules on either the FreeBSD box or the RPi.