[sslh] Bug in transparent proxy with openvpn

[maskim]

Hello,

I have successfully implemented the transparent proxy, but I have a bug with
openvpn and access to local web server.

Here is my configuration :
/usr/local/sbin/sslh --pidfile /var/run/sslh.pid --listen 0.0.0.0:443 --ssh
192.168.1.251:2222 --ssl 192.168.1.251:4430 --openvpn 192.168.1.251:4434
--transparent

sslh, openvpn, ssh and webserver are all running on the same server.

My iptables and ip rules :
iptables -t mangle -N SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport
2222 --jump SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport
4430 --jump SSLH
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport
4434 --jump SSLH
iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
iptables -t mangle -A SSLH --jump ACCEPT
ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Everything works fine, I can access to the websites running on the webserver
on port 4430, VPN is working and I can access to Internet.

But I can't access to the websites hosted on my webserver behind 4430 port.
When removing the -transparent option, it works fine.

Here is a tcpdump of my tun interface :
# tcpdump -i tun0 -n                         
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 
[..]
07:29:54.056674 IP 10.18.0.14.49966 > 192.168.1.251.443: Flags [S], seq
3853722422, win 65535, options [mss 1366,nop,wscale 4,nop,nop,TS val
169662957 ecr 0,sackOK,eol], length 0
07:29:54.056776 IP 192.168.1.251.443 > 10.18.0.14.49966: Flags [S.], seq
3498537013, ack 3853722423, win 14480, options [mss 1460,sackOK,TS val
8807137 ecr 169662957,nop,wscale 7], length 0
07:29:54.100313 IP 10.18.0.14.49966 > 192.168.1.251.443: Flags [.], ack 1,
win 8208, options [nop,nop,TS val 169662998 ecr 8807137], length 0
07:29:54.139678 IP 10.18.0.14.49966 > 192.168.1.251.443: Flags [P.], seq
1:179, ack 1, win 8208, options [nop,nop,TS val 169663003 ecr 8807137],
length 178
07:29:54.139739 IP 192.168.1.251.443 > 10.18.0.14.49966: Flags [.], ack 179,
win 122, options [nop,nop,TS val 8807158 ecr 169663003], length 0
07:29:54.140941 IP 192.168.1.251.4430 > 10.18.0.14.49966: Flags [S.], seq
1599072585, ack 664337644, win 32768, options [mss 16396,sackOK,TS val
8807158 ecr 8807158,nop,wscale 7], length 0
07:29:54.238324 IP 10.18.0.14.49966 > 192.168.1.251.4430: Flags [R], seq
664337644, win 0, length 0
07:29:55.139630 IP 192.168.1.251.4430 > 10.18.0.14.49966: Flags [S.], seq
1614676933, ack 664337644, win 32768, options [mss 16396,sackOK,TS val
8807408 ecr 8807408,nop,wscale 7], length 0
07:29:55.180148 IP 10.18.0.14.49966 > 192.168.1.251.4430: Flags [R], seq
664337644, win 0, length 0
07:29:57.143624 IP 192.168.1.251.4430 > 10.18.0.14.49966: Flags [S.], seq
1645989346, ack 664337644, win 32768, options [mss 16396,sackOK,TS val
8807909 ecr 8807909,nop,wscale 7], length 0
07:29:57.188729 IP 10.18.0.14.49966 > 192.168.1.251.4430: Flags [R], seq
664337644, win 0, length 0
[..]

As you can see, the connection is initiated by a vpn client (IP 10.18.0.14)
to sslh, trying to access the webserver running on port 4430.
At 07:29:54.140941, the response did not come from 443 port but from 4430
port, which causes the client to refuse (reset) it.

When removing the --transparent option (but leaving the iptables and ip
rules), the behavior is different:
10:16:28.851006 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [S], seq
3955393979, win 65535, options [mss 1366,nop,wscale 4,nop,nop,TS val
176950450 ecr 0,sackOK,eol], length 0
10:16:28.851132 IP 192.168.1.251.443 > 10.18.0.14.50399: Flags [S.], seq
2531488512, ack 3955393980, win 14480, options [mss 1460,sackOK,TS val
11305835 ecr 176950450,nop,wscale 7], length 0
10:16:28.897023 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [.], ack 1,
win 8208, options [nop,nop,TS val 176950495 ecr 11305835], length 0
10:16:28.935717 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [P.], seq
1:227, ack 1, win 8208, options [nop,nop,TS val 176950507 ecr 11305835],
length 226
10:16:28.935778 IP 192.168.1.251.443 > 10.18.0.14.50399: Flags [.], ack 227,
win 122, options [nop,nop,TS val 11305857 ecr 176950507], length 0
10:16:28.949077 IP 192.168.1.251.443 > 10.18.0.14.50399: Flags [.], seq
1:1355, ack 227, win 122, options [nop,nop,TS val 11305860 ecr 176950507],
length 1354
10:16:28.950272 IP 192.168.1.251.443 > 10.18.0.14.50399: Flags [.], seq
1355:2709, ack 227, win 122, options [nop,nop,TS val 11305860 ecr
176950507], length 1354
10:16:28.952490 IP 192.168.1.251.443 > 10.18.0.14.50399: Flags [P.], seq
2709:3584, ack 227, win 122, options [nop,nop,TS val 11305861 ecr
176950507], length 875
10:16:29.019077 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [.], ack
2709, win 8107, options [nop,nop,TS val 176950610 ecr 11305860], length 0
10:16:29.068997 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [.], ack
3584, win 8137, options [nop,nop,TS val 176950661 ecr 11305861], length 0
10:16:29.178375 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [P.], seq
227:750, ack 3584, win 8192, options [nop,nop,TS val 176950744 ecr
11305861], length 523
10:16:29.178450 IP 10.18.0.14.50399 > 192.168.1.251.443: Flags [P.], seq
750:756, ack 3584, win 8192, options [nop,nop,TS val 176950744 ecr
11305861], length 6
[..]

As you can see, response comes from 443 port.

Does anyone else have the same problem ?

Best regards,
Maskim