SIP ip forgery :)

Post new topic   Reply to topic    DD-WRT Forum Index -> General Questions
Author Message
bmjdotnet
DD-WRT Novice


Joined: 10 Oct 2017
Posts: 1

PostPosted: Tue Oct 10, 2017 6:06    Post subject: SIP ip forgery :) Reply with quote
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
Sponsor
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> General Questions All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum