So it's understandle the remote ip's would want to communicate on port 1025. Tcpdump confirms that there are outgoing connections from my ip with a source of 1025 when the source should be port 1640. udp 17 180 src=MASQUERADED_INTERNAL_IP dst=EXTERNAL_DST_IP sport=5555 dport=39363 src=EXTERNAL_DST_IP dst=MY_EXTERNAL_IP sport=39363 dport=1025 udp 17 30 src=MASQUERADED_INTERNAL_IP dst=EXTERNAL_DST_IP sport=5555 dport=39363 src=EXTERNAL_DST_IP dst=MY_EXTERNAL_IP sport=39363 dport=1025 $IPT -A DEFAULT_OUT -p udp -m udp -m multiport -dports 53,123 -j ACCEPTĬonntrack shows the outgoing source port as port 5555 and expects it to return on port 1025. $IPT -A DEFAULT_OUT -p icmp -m icmp -icmp-type 8/0 -j ACCEPT $IPT -A DEFAULT_IN -p icmp -m icmp -icmp-type 11/1 -j ACCEPT $IPT -A DEFAULT_IN -p icmp -m icmp -icmp-type 11/0 -j ACCEPT $IPT -A DEFAULT_IN -p icmp -m icmp -icmp-type 0/0 -j ACCEPT $IPT -A DEFAULT_IN -p icmp -m icmp -icmp-type 3 -j ACCEPT $IPT -A DEFAULT_IN -p icmp -m icmp -icmp-type 12 -j ACCEPT $IPT -A DEFAULT_FWD_OUT -p udp -m udp -m multiport -sports 5555,123,53 -j ACCEPT $IPT -A DEFAULT_FWD_OUT -p icmp -m icmp -icmp-type 8/0 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p udp -m udp -dport 5555 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p icmp -m icmp -icmp-type 11/1 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p icmp -m icmp -icmp-type 11/0 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p icmp -m icmp -icmp-type 0/0 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p icmp -m icmp -icmp-type 3 -j ACCEPT $IPT -A DEFAULT_FWD_IN -p icmp -m icmp -icmp-type 12 -j ACCEPT $IPT -A FORWARD -i $EXTIF -o $INTIF -j DEFAULT_FWD_IN $IPT -A FORWARD -i $INTIF -o $EXTIF -j DEFAULT_FWD_OUT $IPT -A FORWARD -i $EXTIF -o $INTIF -m state -state ESTABLISHED,RELATED -j ACCEPT $IPT -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE These are the relevant iptables rules: $IPT -t nat -A PREROUTING -i $EXTIF -p udp -m udp -dport 5555 -j DNAT -to-destination $WIN_IP:5555 I can only guess these ip's that were working correctly were new connections that came in after the service was restarted. However some of the connections to different ips were being sent out on the correct port. Then tcpdump reported the connections were being sent from my external ip on port >=1024 when they should have been getting sent from the original port. But they transferred it to where it never got answered. I posted this on where my question might have been answered. I've been trying to hunt this down for over a month. So, I've blocked all outgoing traffic from the service on the windows box on port 1024/1025 because that's where the bulk of the traffic lies.īut the problem still exists. There are udp connections coming from Windows 7 on both the original service port and port >=1024 but this may be because the bad connections/configuration from the linux box poisoned the service on the windows box. One packet goes out the original port from the masqueraded ip and returns on a different port on the external ip but the packet also somehow gets routed to the correct port on the masqueraded ip. Whenever I have UDP traffic to a specific port, if I shut down the service or close the port too long when I bring the service back up I get floods of connections coming into port >=1024 instead of the port that the service runs on. I have a problem with UDP and NAT specifically with MAQUERADING AND FORWARDING. These problems existed on Slackware 64 14.0, I moved to gentoo because Slackware doesn't support many security features, like selinux, app armor, grsecurity, etc. Hardened with grsecurity and selinux with a strict policy in enforcing mode Linux Gentoo 3.13.6-hardened-r3 #1 SMP Sat Apr 12 09:17: x86_64 Intel(R) Core(TM) 1.86GHz GenuineIntel GNU/Linux
0 Comments
Leave a Reply. |