no internet access/traffic with mitmproxy (wireguard mode)

[bertlebee]

Firstly, thanks for this awesome project!

I'm trying to use this to set up a vlan for mitmproxy/wireshark (i.e anything that connects to the vlan gets intercepted) to assist with some reverse engineering projects that I have on the go. I think I'm nearly there after searching through other issues, but I'm now properly stuck.

mitmproxy has a wireguard mode https://docs.mitmproxy.org/stable/concepts-modes/#wireguard-transparent-proxy which makes this project a great match (conceptually at least!)

some context:

• I've got a UDMPRO set up as my gateway (10.1.1.1) with split-vpn installed
• no black hole routes/killswitch as I don't really care about leaking traffic on startup given my usecase
• I've created a vlan (10.6.6.6/24), and a wireless network called "mitm" connected to it
• mitmproxy in wireguard mode is running on 10.1.1.8
• adguard home DNS is running on 10.1.1.23, upstream defers to my UDMPRO DNS
• I only care about IPv4. IPv6 is disabled on this vlan
• I have a few other vlans in 10.1.0.0/48 for guests/smart devices under local control/smart devices under manufacturer control etc)

I can connect to the "mitm" wireless network but my traffic is not showing up in mitmproxy and I can't access the internet from this network. My mobile has been assigned 10.6.6.196 on this network, so should be in the forced IP range. My DNS and mitmproxy/wireguard server are in the 10.1.1.0/24 (exempt destinations) range so should be accessible.

Can you see anything wrong with my config? Any hints/suggestions would be very much appreciated.

I've checked there's no network isolation or content filtering enabled on this vlan and there's no client isolation/guest portal etc enabled on the wireless network.

here are my config files:

wg0.conf

this is copied from mitmproxy startup then edited as follows:

• changed Allowed IPs from 0.0.0.0 due to raw IP tables issue Unable to initialize table 'raw' #117
• removed DNS entry
• added PostUp/PreDown per instructions
• added Table per instructions (I don't know if 101 is correct/matters? it's the same in vpn.conf. I've also tried 201 in both but that broke all my networks and I had to restart my gateway to get back online! )

[Interface]
PrivateKey = ***
Address = 10.0.0.1/32
PostUp = sh /etc/split-vpn/vpn/updown.sh %i up
PreDown = sh /etc/split-vpn/vpn/updown.sh %i down
Table = 101

[Peer]
PublicKey = ***
AllowedIPs = 0.0.0.0/1,128.0.0.0/1
Endpoint = 10.1.1.8:51820

vpn.conf

### SPLIT VPN OPTIONS ###
# Enter multiple entries separated by spaces.
# Do not enter square brackets around the entries.

# Force these sources through the VPN.
# Format: [brX] for interface. [IP/nn] for IP. [xx:xx:xx:xx:xx:xx] for mac.
FORCED_SOURCE_INTERFACE=""
FORCED_SOURCE_IPV4="10.6.6.6/24"
FORCED_SOURCE_IPV6=""
FORCED_SOURCE_MAC=""

# Format: [tcp/udp/both]-[IP/MAC Source]-[port1,port2:port3,port4,...]
# Maximum 15 ports per entry.
FORCED_SOURCE_IPV4_PORT=""
FORCED_SOURCE_IPV6_PORT=""
FORCED_SOURCE_MAC_PORT=""

# Force these destinations through the VPN.
# These destinations will be forced regardless of source.
# Format: [IP/nn]
FORCED_DESTINATIONS_IPV4=""
FORCED_DESTINATIONS_IPV6=""

# Force local UDM traffic going out of these WAN interfaces to go through the
# VPN instead for both IPv4 and IPv6 traffic.
# This does not include routed traffic, only local traffic generated by the UDM.
# Do not enable this unless you want to force UDM local traffic through the VPN.
# For UDM-Pro, set to "eth8" for WAN1/Ethernet port, or "eth9" for WAN2/SFP+ port,
# or "eth8 eth9" for both. For UDM Base, set to "eth1" for the WAN port.
# This option might cause unintended problems, so disable it if you encounter any issues.
FORCED_LOCAL_INTERFACE=""

# Exempt these sources from the VPN.
# Format: [IP/nn] for IP. [xx:xx:xx:xx:xx:xx] for mac.
EXEMPT_SOURCE_IPV4=""
EXEMPT_SOURCE_IPV6=""
EXEMPT_SOURCE_MAC=""

# Format: [tcp/udp/both]-[IP/MAC Source]-[port1,port2:port3,port4,...]
# Maximum 15 ports per entry.
EXEMPT_SOURCE_IPV4_PORT=""
EXEMPT_SOURCE_IPV6_PORT=""
EXEMPT_SOURCE_MAC_PORT=""

# Exempt these destinations from the VPN.
# Format: [IP/nn]
EXEMPT_DESTINATIONS_IPV4="10.1.1.0/24"
EXEMPT_DESTINATIONS_IPV6=""

# Force/exempt these IP sets
# IP sets need to be created before this script is run or the script will error.
# IP sets can be updated externally and will be matched dynamically.
# Each IP set entry consists of the IP set name and whether to match on source
# or destination. src/dst needs to be specified for each IP set field.
#
# Enable NAT hairpin by exempting UBIOS_ADDRv4_ethX:dst for IPv4 or
# UBIOS_ADDRv6_ethX:dst for IPv6 (where X = 8 for RJ45, or 9 for SFP+ WAN).
# For IPv6 prefix delegation, exempt UBIOS_ADDRv6_brX, where X = VLAN number (0 = LAN).
#
# To allow communication with your VLAN subnets without hardcoding the subnets,
# exempt the UBIOS_NETv4_brX:dst ipset for IPv4 or UBIOS_NETv6_brX:dst for IPv6.
#
# Format: [IPSet Name]:[src/dst,src/dst,...]
FORCED_IPSETS=""
EXEMPT_IPSETS=""

# VPN port forwards.
# Format: [tcp/udp/both]-[VPN Port]-[Forward IP]-[Forward Port]
PORT_FORWARDS_IPV4=""
PORT_FORWARDS_IPV6=""

# Redirect IPv4 and IPv6 DNS to these addresses for VPN-destined traffic.
# Note that many VPN providers redirect DNS going through their VPN network
# to their own DNS servers. Redirection to other IPs might not work on all providers,
# except for DNS redirects to a local address, or rejecting DNS traffic completely.
#
# IPV4 Format: [IP] to redirect to IP, "DHCP" if using OpenVPN or OpenConnect to obtain
# DNS from DHCP options, or "REJECT" to reject all DNS traffic. "DHCP" is not supported on
# other VPN types like wireguard/external.
#
# Example: Get DNS from DHCP
DNS_IPV4_IP="10.1.1.23"
DNS_IPV4_PORT=53
# Set this to the interface (brX) the DNS is on if it is a local IP. Leave blank for
# non-local IPs. Local DNS redirects will not work without specifying the interface.
DNS_IPV4_INTERFACE="br0"

# IPV6 Format: [IP] to redirect to IP, or "REJECT" to reject IPv6 DNS traffic completely.
# IPV6 Format: [IP] to redirect to IP, "DHCP" if using OpenConnect to obtain DNS from DHCP
# options, or "REJECT" to reject all DNS traffic. "DHCP" is not supported on
# other VPN types.
DNS_IPV6_IP=""
DNS_IPV6_PORT=53
DNS_IPV6_INTERFACE=""

# Bypass masquerade (SNAT) for these source IPs. This option should only be used if your
# VPN server is setup to know how to route the subnet you do not want to masquerade
# (e.g.: the "iroute" option in OpenVPN).
# Set these options to ALL to disable masquerading completely.
# Format: [IP/nn] or "ALL"
BYPASS_MASQUERADE_IPV4=""
BYPASS_MASQUERADE_IPV6=""

# Enabling kill switch drops VPN-destined traffic that doesn't go through the VPN.
KILLSWITCH=0

# Enable this only if you are testing or you don't care about your real IP leaking
# when the vpn client restarts or exits.
REMOVE_KILLSWITCH_ON_EXIT=1

# Enable this if you added blackhole routes in the Unifi Settings to prevent Internet
# access at system startup before the VPN script runs. This option removes the blackhole
# routes to restore Internet access after the killswitch has been enabled.
# If you do not set this to 1, openvpn will not be able to connect at startup, and your
# Internet access will never be enabled until you manually remove the blackhole routes.
# Set this to 0 only if you did not add any blackhole routes.
REMOVE_STARTUP_BLACKHOLES=0

# Set the VPN provider.
# "openvpn" for OpenVPN (default), "openconnect" for OpenConnect, "external" for wireguard,
# or "nexthop" for an external VPN client.
VPN_PROVIDER="external"

# If using "external" for VPN_PROVIDER, set this to the VPN endpoint IP so that the
# gateway route can be automatically added for the VPN endpoint.
# OpenVPN passes the VPN endpoint IP to the script and will override these values.
# These must be defined if using VPN_PROVIDER="nexthop".
VPN_ENDPOINT_IPV4="10.1.1.8"
VPN_ENDPOINT_IPV6=""

# Set this to the route table that contains the gateway route, "auto", or "disabled".
# The Ubiquiti route table is "201" if you're using Ethernet, "202" for SFP+, and
# "203" for U-LTE.
# Default is "auto" which works with WAN failover and automatically changes the endpoint
# via gateway route when the WAN or gateway routes changes.
# Set to "disabled" if you are using the nexthop option to connect to a VPN on your LAN.
GATEWAY_TABLE="auto"

# Set the MSS clamping on packets going out the VPN tunnel. Usually, it is not needed to
# set this manually, but some VPN connections stall if the MSS clamping is not set correctly.
# Typical values range from 1240 to 1460, but it could be lower.
MSS_CLAMPING_IPV4=""
MSS_CLAMPING_IPV6=""

# Set this to the timer to use for the rule watcher (in seconds).
# The script will wake up every N seconds to re-add rules if they're deleted by
# the system, or change gateway routes if they changed. Default is 1 second.
WATCHER_TIMER=1

# Options for custom table and chains.
# These options need to be unique for each instance of openvpn if running multiple.
ROUTE_TABLE=101
MARK=0x169
PREFIX="VPN_"
PREF=99
DEV=wg0
# To execute commands when the VPN connects or disconnects, you can use the
# callback functions hooks_pre_up, hooks_up, hooks_down, and
# hooks_force_down. These functions will be invoked in response to VPN events
# pre-up, up, down, and force-down respectively.
#
# For an example on using these hooks, please see vpn.conf.filled.sample.

[bertlebee]

Does the script assume the VPN is external? I think that's what 10.1.1.8 via [my public IP] dev eth8 implies but I'm far from an expert on these matters!

root@UDMPRO:/etc/split-vpn/wireguard/mitmproxy# ip route show table 101
0.0.0.0/1 dev wg0 scope link
blackhole default
10.1.1.8 via [my public IP] dev eth8
128.0.0.0/1 dev wg0 scope link

Some extra info/tests:

When the vpn is up:
from mitm vlan:

• ping 1.1.1.1
• ping 10.1.1.1 (my udmpro/gateway)
• ping 10.1.1.23 (dns)
• ping 10.1.1.8 (mitmproxy/wireguard server)
• nslookup google.com

from my normal home network (10.1.1.0/24) same laptop as I used for above)

• ping 1.1.1.1
• ping 10.1.1.1 (my udmpro/gateway)
• ping 10.1.1.23 (dns)
• ping 10.1.1.8 (mitmproxy/wireguard server)
• nslookup google.com

from 10.1.1.8 (mitmproxy/wireguard server)

• ping 1.1.1.1
• ping 10.1.1.1 (my udmpro/gateway) <---- this one surprised me!
• ping 10.1.1.23 (dns)
• ping 10.1.1.8 (mitmproxy/wireguard server)
• nslookup google.com

Throughout all of this, mitmproxy didn't record a single bit of traffic

When the vpn is down, all these commands work fine