-Sigh- Well, Microsoft has done it, again. I think I've finally located the problem, and the solution is going to be a bit more difficult - maybe impossible - for SNAT to handle (I think). I was doing some packet sniffing and noticed that I was not getting any attempts to reply to messages sent on port 138 for my machines by my NAT router. I started looking into the packets, and, guess what? On NetBIOS datagram packets (port 138), Microsoft has decided to embed the IP address of the original requesting machine in the packet, rather than just using the information already on the IP header. I'm guessing they did this to try to make an already unsecure protocol a bit more secure, but it is defeating the SNAT'ing I'm trying to do on my network. In looking at the packet in Wireshark, the "NetBIOS Datagram Service" portion of the packet has Source IP and Source Port fields. So, in addition to standard NAT'ing, I'm going to have to "mangle" these fields in the packet, too. I'm not even sure that's possible, even in a connection tracking helper module - any hints would be greatly appreciated. -Nick -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
