Forum Discussion
Hi Brad,
I removed the route domain I added earlier and restored all the other settings accordingly and confirmed the SOCKS function still worked as before. Then I tried your suggestion and a couple of variations including using the MAC address of my inside firewall's outside interface and including and excluding the vlan name with the IP address of the inside firewall's external interface, but the LTM always ignores the
nexthop
setting. I added some logging to see what's going on.
when SOCKS_REQUEST {
if { [class match [SOCKS::destination] ends_with SOCKS_whitelist] } {
log -noname local6.notice "[virtual name]: SOCKS request from client at [IP::remote_addr] for host [SOCKS::destination] allowed"
set socksAllowed 1
SOCKS::allowed 1
} else {
log -noname local6.warning "[virtual name]: SOCKS request from client at [IP::remote_addr] for host [SOCKS::destination] blocked"
set socksAllowed 1
SOCKS::allowed 0
}
log -noname local6.warning "[virtual name]: In SOCKS_REQUEST event; nexthop = [LINK::nexthop name]; [LINK::nexthop]"
}
when SERVER_CONNECTED {
if { $socksAllowed }{
nexthop internal 10.239.127.33
log -noname local6.warning "[virtual name]: In SERVER_CONNECTED event; nexthop = [LINK::nexthop name]; [LINK::nexthop]"
}
}
When inside the SOCKS_REQUEST event, the log shows (as I'd expect):
/Common/vs_self_SOCKS: In SOCKS_REQUEST event; nexthop = unknown; ff:ff:ff:ff:ff:ff
When inside the SERVER_CONNECTED event, after setting
nexthop
, the log shows:
/Common/vs_self_SOCKS: In SERVER_CONNECTED event; nexthop = loopback; 00:01:4c:4f:4f:50
The LTM still routes the traffic according to the routing table. In the case of a request for google.com, for example, that's out the external interface and the connection is successful.
There seems to be something special about using the SOCKS service that disallows the use of
nexthop
.
Regards,
Steve