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



  • 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.



  • 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?


  • LAYER 8 Rebel Alliance

    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



  • 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.


  • LAYER 8 Rebel Alliance

    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:
    0_1547112943325_floating_reject.png

    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



  • 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
    Reject Rule
    Floating Rule Reject
    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.


  • LAYER 8 Rebel Alliance

    You need to bind the Alias to WAN not LAN.

    -Rico



  • @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.