You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to use SSLH in transparent mode. as per the instruction this require some iptables+ ip instructions as follows:
iptables -t mangle -N SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 22 --jump SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 4443 --jump SSLH
iptables -t mangle -A SSLH --jump MARK --set-mark 1
iptables -t mangle -A SSLH --jump ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
The problem is that once the last one is given the box became unreachable (tested on several pine64 distro, same result).
The very same instructions works fine with other linux boxes, even with arm processors, and even some kernel older than 3.10.
It seems as if the kernel (or some module) "fwmarks" all the packets instead of just the selected ones, hence disrupting the network connectivity.
Once the instructions are given no traffic from the box to the lan works either.
Could this depend on some quirks on this kernel?
Thanks
The text was updated successfully, but these errors were encountered:
I'm trying to use SSLH in transparent mode. as per the instruction this require some iptables+ ip instructions as follows:
iptables -t mangle -N SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 22 --jump SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 4443 --jump SSLH
iptables -t mangle -A SSLH --jump MARK --set-mark 1
iptables -t mangle -A SSLH --jump ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
The problem is that once the last one is given the box became unreachable (tested on several pine64 distro, same result).
The very same instructions works fine with other linux boxes, even with arm processors, and even some kernel older than 3.10.
It seems as if the kernel (or some module) "fwmarks" all the packets instead of just the selected ones, hence disrupting the network connectivity.
Once the instructions are given no traffic from the box to the lan works either.
Could this depend on some quirks on this kernel?
Thanks
The text was updated successfully, but these errors were encountered: