SOCKS5 proxy (dante) on Virtual IP to use OpenVPN (ovpnc1) as Gateway

BearTM

Latest 2.4.4-RELEASE-p1 (amd64)

pfSense LAN IP = 192.168.1.254
Virtual IP = 192.168.1.253

The goal is to have a local SOCKS5 proxy which would use an OpenVPN Client connection as gateway. (i.e. able to selectively use proxy over VPN)

I've installed a SOCKS5 proxy (dante) using the following:

pkg add http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/cyrus-sasl-2.1.27.txz
pkg add http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/miniupnpc-2.1_1.txz
pkg add http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/dante-1.4.2_1.txz

configured: /usr/local/etc/sockd.conf

errorlog: syslog
logoutput: /var/log/sockd.log
#debug: 1

# accept connections going to this address.
internal: 192.168.1.254 port = 1080

# external IP to use 192.168.1.253
external: 192.168.1.253

# server identities
user.privileged: root
user.notprivileged: nobody

# methods for socks-rules.
socksmethod: none

# methods for client-rules.
clientmethod: none

# permit clients inbound to the proxy
client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: error #connect disconnect
}

# generic pass statement - bind/outgoing traffic
socks pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error #connect disconnect iooperation
}

# generic pass statement for incoming connections/packets
socks pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bindreply udpreply
        log: error #connect disconnect iooperation
}

Automatic Startup: /cf/conf/config.xml
[added immediately before </system>]

<shellcmd>/usr/local/etc/rc.d/sockd onerestart</shellcmd>

Testing the SOCKS5 server, it's working properly. All requests are proxied, and the states are visible in the states table with WAN_IP:(192.168.1.253:1080) -> External_IP.

However, now no matter what rules I add to LAN, WAN, or Floating - I'm unable to force all traffic from the Virtual IP (192.168.1.253) to exit using the OpenVPN Gateway. All traffic always goes out the WAN interface.

i.e. Firewall -> Rules -> LAN -> Add Rule
Pass / LAN / IPv4 / Protocol: any / Source: 192.168.1.253 / Destination: any / Gateway: VPN_GW
Does not work. It doesn't even get triggered/logged.

What am I missing? Are Virtual IPs unable to have firewall rules applied and/or unable to be routed out a different gateway?

I simply want all traffic originating from the Virtual IP 192.168.1.253 to go out a different gateway, but I'm unable to achieve this.

Traceroute from OpenVPN Address - exits over OpenVPN Gateway.
Traceroute from Virtual IP (192.168.1.253) - exits over WAN Gateway.

Any help would be appreciated. I feel I'm missing something obvious about Virtual IP usage and Firewall Rules ...

Cheers.

BearTM

Hi guys - no answers?

FYI: A setup like this (SOCKS5 Proxy to VPN) is useful for ensuring a specific application (like a torrent) will always be routed through a VPN, instead of the default Gateway.

Any help on how to properly route a Virtual IP through a specific Gateway, and not through the default one?

In all my testing - LAN/WAN/Floating firewall rules specifying the Virtual IP as source do not work.

Help?

Rico

I'm no Floating Rules expert but try to help when no one give it a shot. ;-)
The reason is that NAT happens first and you loose your Source address then.
Processing order:

Outbound NAT rules
Inbound NAT rules such as Port Forwards (including rdr pass and UPnP)
NAT rules for the Load Balancing daemon (relayd)
Rules dynamically received from RADIUS for IPsec and OpenVPN clients
Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)
User-defined rules:
- Rules defined on the floating tab
- Rules defined on interface group tabs (Including IPsec and OpenVPN)
- Rules defined on interface tabs (WAN, LAN, OPTx, etc)
Automatic VPN rules

A workaround could be to Tag that traffic as it enters your LAN interface.
Then in a floating Rule use Tagged with the same string.

-Rico

BearTM

Thank you so much for the help. I've tried adding rules, tagging the traffic (on all interfaces), trying to log/block/capture it anywhere, but I've unfortunately been entirely unsuccessful in this endeavour.

To see if I can get ANY firewall rule to fire, I added 2 BLOCK rules to Floating, WAN, and LAN with the Virtual IP Address being used (192.168.1.253) by the dante (SOCKS5 proxy) daemon for exit/egress - with either Source or Destination match with logging. None of the rules were ever blocked or logged.

Do Virtual IPs (used by a running service/daemon on the firewall itself) not pass through the firewall rules? I can't seem to block the Virtual IP at all.

To test:
1). Create a Virtual IP.
2). Perform a Traceroute to "google.com" exiting using the Virtual IP as source.
3). It will succeed, and exit the Default Gateway.
4). Attempt to BLOCK the Traceroute from being able to exit the server with any combination of Firewall Rules.

I can't affect/log/block the traffic in any way.

I'm wondering if the Virtual IP is bypassing the firewall rules, but that wouldn't make sense - which means I must be doing something wrong. Any suggestions on how to trace the packet routing?

Cheers.

Rico

I have a Test pfSense in VM with WAN IP 192.168.74.131
Ping google.com

PING google.com (172.217.23.142) from 192.168.74.131: 56 data bytes
64 bytes from 172.217.23.142: icmp_seq=0 ttl=128 time=21.734 ms
64 bytes from 172.217.23.142: icmp_seq=1 ttl=128 time=9.803 ms
64 bytes from 172.217.23.142: icmp_seq=2 ttl=128 time=56.492 ms

--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.803/29.343/56.492/19.806 ms

Now I added VIP 192.168.74.132 to WAN, google.com test again

PING google.com (172.217.23.142) from 192.168.74.132: 56 data bytes
64 bytes from 172.217.23.142: icmp_seq=0 ttl=128 time=33.770 ms
64 bytes from 172.217.23.142: icmp_seq=1 ttl=128 time=18.254 ms
64 bytes from 172.217.23.142: icmp_seq=2 ttl=128 time=8.950 ms

--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.950/20.325/33.770/10.238 ms

Now I added a Floating Rule for WAN with action REJECT, Direction Out, Protocol Any, Source is my VIP 192.168.74.132
Ping to google.com from this VIP stop working as expected:

PING google.com (172.217.23.142) from 192.168.74.132: 56 data bytes

--- google.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

It's also in my Firewall Logs:

Traffic from the Firewall IP is still working:

PING google.com (172.217.23.142) from 192.168.74.131: 56 data bytes
64 bytes from 172.217.23.142: icmp_seq=0 ttl=128 time=14.115 ms
64 bytes from 172.217.23.142: icmp_seq=1 ttl=128 time=10.154 ms
64 bytes from 172.217.23.142: icmp_seq=2 ttl=128 time=25.825 ms

--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.154/16.698/25.825/6.653 ms

So I can tell you VIP Traffic 100% passes the Firewall.
Maybe you can post Screenshots with your Settings?

-Rico

BearTM

Hi Rico,

Thank you for helping me with this - but even with replicating your settings, I've been unsuccessful. I even tried another/different/new Virtual IP.

Virtual IP
![Virtual IP]
(https://plik.root.gg/file/zSWKFkgwuXR2Jq5X/HI5DN4UKyT8c8Y2s/virtual_ip.jpg)
Reject Rule

Floating Rule Reject

Ping still succeeds???
Ping Succeeds???

I'm also running pfSense in a VM (Ubuntu/KVM), and I'm at a loss for why I'm unable to get the Firewall Rules to apply to the Virtual IP address.

I'd done exactly what you have specified myself earlier - because that configuration absolutely makes sense. I'm ripping my hair out, because I have no idea why that same floating WAN reject rule is not working on my machine.

Could I have (somehow) enabled another setting which "skips" firewall rules?

It just doesn't make sense. I should have had this sorted, because the concept/routing/requirements are absolutely trivial.

Cheers.

Rico

You need to bind the Alias to WAN not LAN.

-Rico

BearTM

@rico - Apologies for the slow reply.

In the screenshots, the IP Alias is bound to LAN (can't be otherwise).

Also, the floating rule was bound to BOTH of LAN and WAN (I was trying anything), but having the rule bound only to LAN or only to WAN has the same issue - every ping gets through.

Do you know of any global settings which may be changed (i.e. I have them incorrect)? It doesn't make any sense to me that these rules are not being applied.

Cheers.

Jim Coogan

@BearTM did you ever have any luck with this or a similar socks -> vpn gateway setup? I have been wanting to do this for a while.

Bob.Dig

I also need dante on pfSense but it is not working with a OVPN client. If anyone got an idea, please let me know.

I now use dante on a separate host and do policy route the gateway to the OVPN client which works just fine. But I would prefer to run a socks5 proxy on pfSense. Squid doesn't do it for me.

Taxy

@beartm this is exactly what i want to do but those pkg add commands say not found, i assume because there is newer versions now how do i find the latest/current?

thanks

BearTM

@taxy Thread Necromancy! 2019?!!? Wow. :)

Anyways ... I never did get the Socks proxy working, and I ended up using packet tagging and Gateway routes to solve the problem.

Packets tagged with a specified "Go out the VPN" tag are then routed out a specific (VPN) Gateway instead of the default one. Similarly, routing rules can be added to do this by IP address or Alias.

In this way I've got multiple VPN routes active, where specific machines can not DNS leak (route all packets over VPN), others can bridge (use all networks), and others use tagged packets to only route specific connections. The Proxy was too much work for too little gain.

Taxy

@beartm yeah sorry to bring this thread back to life but it was exactly what i'm trying to do!

so how do you route certain traffic through pfsense or does all your traffic go through it? i was trying to setup socks5 proxy so i can configure it in certain applications and then i know all traffic from that application is using it and then going through the VPN (i've forced all traffic via the VPN on my pfsense box).