bmjdotnet DD-WRT Novice
Joined: 10 Oct 2017 Posts: 1
|
Posted: Tue Oct 10, 2017 6:06 Post subject: SIP ip forgery :) |
|
Hi All,
Long time listener, first time caller. Posting in GQ because I don't think this is a hardware-specific issue. The short of it is that dd-wrt is mysteriously re-writes the IP header of SIP (5060) packets incorrectly with the WAN IP address even when they're routed down a tunnel. Details to follow (IPs changed to protect the guilty)...
I have DD-WRT v3.0-r30796 std (10/25/16) running on a LinkSys WRT3200ACM at a remote location. I have manhandled an openvpn tunnel (tun1 - there is no tun0) that establishes upon reboot or tunnel drop. The remote site is 192.168.5.0/24 and the central site is 10.0.0.0/8. I am able to successfully communicate from 10/8 network to the 192.168.5/24 network and vice versa with no issues (traffic correctly NATs when going out of WAN to public, and doesn't NAT when going down the tunnel to 10/8 ) - verified with tcpdump on all sides.
However, when the IP phone on 192.168.5.131 tries to communicate with the PBX on 10.25.0.10, the router incorrectly re-writes the IP header of the SIP packet with the WAN address, and then correctly sends that forged packet down the tunnel. On the central site, I see the packets coming out the tunnel with the public address of the remote site. Examples below:
Simultaneous dumps of the LAN and tunnel interfaces on the router:
Code: | root@housecat:~# tcpdump -i br0 port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:47:36.100035 IP 192.168.5.131.5060 > pbx.foo.bar.5060: SIP, length: 575
00:47:40.103781 IP 192.168.5.131.5060 > pbx.foo.bar.5060: SIP, length: 575
00:47:44.107619 IP 192.168.5.131.5060 > pbx.foo.bar.5060: SIP, length: 575 |
Code: | root@housecat:~# tcpdump -i tun1 port 5060
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
00:47:36.100260 IP wan.ip.comcast.net.5060 > pbx.foo.bar.5060: SIP, length: 575
00:47:40.104010 IP wan.ip.comcast.net.5060 > pbx.foo.bar.5060: SIP, length: 575
00:47:44.107844 IP wan.ip.comcast.net.5060 > pbx.foo.bar.5060: SIP, length: 575 |
I also verified from the router on the nearend (central site, pfsense):
Code: | [2.3.2-RELEASE][root@walnut.foo.bar]/root: tcpdump -i ovpns2 port 5060
listening on ovpns2, link-type NULL (BSD loopback), capture size 65535 bytes
00:47:36.396918 IP wan.ip.comcast.net.sip > pbx.foo.bar.sip: SIP, length: 577
00:47:40.401568 IP wan.ip.comcast.net.sip > pbx.foo.bar.sip: SIP, length: 577
00:47:44.404977 IP wan.ip.comcast.net.sip > pbx.foo.bar.sip: SIP, length: 577 |
I have poked through iptables (both NAT and MANGLE) and don't see anything that would single out SIP traffic specifically (and otherwise the rules are operating correctly, not molesting 10/8<->192.168.5/24 traffic).
MANGLE rules:
Code: | root@housecat:~# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 61M packets, 56G bytes)
pkts bytes target prot opt in out source destination
489 29436 MARK 0 -- !eth0 * 0.0.0.0/0 X.X.X.X MARK or 0x80000000
61M 56G CONNMARK 0 -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save
Chain INPUT (policy ACCEPT 675K packets, 198M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 60M packets, 56G bytes)
pkts bytes target prot opt in out source destination
142K 8404K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 422K packets, 166M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 60M packets, 56G bytes)
pkts bytes target prot opt in out source destination |
NAT rules:
Code: | root@housecat:~# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 877K packets, 208M bytes)
pkts bytes target prot opt in out source destination
98 3510 DNAT icmp -- * * 0.0.0.0/0 X.X.X.X to:192.168.5.1
213K 81M TRIGGER 0 -- * * 0.0.0.0/0 X.X.X.X TRIGGER type:dnat match:0 relate:0
Chain INPUT (policy ACCEPT 102K packets, 7590K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 44166 packets, 3278K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 46551 packets, 3621K bytes)
pkts bytes target prot opt in out source destination
127K 13M SNAT 0 -- * eth0 192.168.5.0/24 0.0.0.0/0 to:X.X.X.X
0 0 MASQUERADE 0 -- * * 0.0.0.0/0
0.0.0.0/0 mark match 0x80000000/0x80000000 |
I have verified that dd-wrt is NOT actually re-writing the SIP register/invite headers, and is only molesting the IP header. I have (to the best of my ability) made sure that milkfish and other SIP crap is disabled. I did go so far as to poke around the process tree, but didn't find anything interesting:
Code: | root@housecat:~# ps |grep -v \\[
PID USER VSZ STAT COMMAND
1 root 1352 S /sbin/init earlyprintk
807 root 772 S /sbin/hotplug2 --set-rules-file /etc/hotplug2.rules --persistent
814 root 1612 S watchdog
1099 root 2256 S hostapd -B -P /var/run/ath0_hostapd.pid /tmp/ath0_hostap.conf
1123 root 2256 S hostapd -B -P /var/run/ath1_hostapd.pid /tmp/ath1_hostap.conf
1149 root 2256 S hostapd -B -P /var/run/ath2_hostapd.pid /tmp/ath2_hostap.conf
1228 root 1092 S telnetd
1263 root 844 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_host_rsa_key -p 22 -a
1276 root 1184 S dnsmasq -u root -g root --conf-file=/tmp/dnsmasq.conf --cache-size=1500
1349 root 1468 S ttraff
1354 root 2096 S startstop_f run_rc_startup
1356 root 1092 S {.rc_startup} /bin/sh /tmp/.rc_startup
1363 root 1092 S {watcher.sh} /bin/sh /tmp/openvpncl/watcher.sh
1501 root 1564 S resetbutton
1569 root 4016 S httpd -p 80
1696 root 1348 S process_monitor
1700 root 1284 S inadyn -u dynuser -p dynpass --input_file /tmp/ddns/inadyn.conf
1703 root 1588 S wland
1723 root 752 S igmprt /tmp/igmpproxy.conf
1724 root 1092 S udhcpc -i eth0 -p /var/run/udhcpc.pid -s /tmp/udhcpc -O routes -O msstaticroutes -O staticro
1735 root 720 S cron
1740 root 1596 S snmpd -c /var/snmp/snmpd.conf
1761 root 2984 S openvpn --log /tmp/openvpncl/run.log --config /tmp/openvpncl/openvpn.conf
22171 root 916 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_host_rsa_key -p 22 -a
22172 root 1096 S -sh
22962 root 1092 S sleep 60
22998 root 1092 R ps
25110 root 916 S dropbear -b /tmp/loginprompt -r /tmp/root/.ssh/ssh_host_rsa_key -p 22 -a
25113 root 1100 S -sh |
So, can anyone shed some light on why dd-wrt is doing this, or point me in the right direction of whom to ask? Thanks so much in advance.
/b |
|