I'm trying to transmit data in UDP datagrams into a client in external location to a pc in my local lan. But my network is over a ADSL modem sending to a pc with Slackware, this pc redirect packages into other pcs. I'm using socat to redirect UDP:
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
In LAN the conection is fine, but external IPs don't work. Somebody help?
I don't think socat is the culprit, however consider to use stone instead of socat, because using a fork() for each received packet is a bit weird. Stone is called in your case like this (I think):
stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udp
Now why external IPs perhaps do not work. Sadly your text does not tell much about your setup, so I have to guess:
It depends on your firewall/modem/router if it is able to forward UDP packets. Usually, if you initiate the UDP requests from the inside, the router will open a NAT connection, which often means, that not only the source IP of the packets change, but the source port as well. As UDP is connectionless, UDP NAT connections usually time out very quickly, say after 5 minutes, if no data is transferred on them.
If the UDP must be opened in the opposite direction (from Internet to Intranet), the router usually discards all the UDP packets coming in from Internet, because it does not know where to forward them to. A router cannot just choose some arbitrary machine, this would be a security hole. So in the "Internet connecting to a machine behind the router" you must open the UDP port on the router and let it forward to the right machine. In that case packets sent from your internal machine will get their source IP and the source port rewritten, the machine on the Internet always will see the packets as coming from your router. So except for the additional rule in the router this case is the same as the outgoing case.
Note that there are several different ways how to make NAT (symmetric, etc.) and several methods on how to open a port on the router (Config, UPnP, etc.) so the ways to poke some holes into it always depends on your hardware capabilities. This all cannot be answered here.
Some other ideas what might go wrong as well:
Some UDP protocols encode IP addresses within the payload. In that case it is not enough just to forward the packets, you must change the payload as well to correct the IP addresses exchanged to enable all machines to talk together. Such UDP protocols are badly designed, anyway, because you never should assume that two arbitrary machines can directly talk with each other, so all good protocols should support easy proxying.
Some ISPs filter certain UDP ports, for arbitrary reason. If you have problems talking from Internet to your DSL, try with two external machines directly connected to different ISPs. If these can talk via UDP check if you can talk from your Intranet to one of the external machines. If this still works, this means, that you can talk backwards as well, as usually UDP is not a directed protocol, but if there is some NAT involved you somehow must make sure that the communication ports stay open.
Mobile Internet plans often do not support P2P. This probably means, those plans do not support Internet at all, as IP, by definition, is P2P. What the ISPs really want to say with "no P2P" is (my guess), that connections from Internet to the mobile device are not supported. In that case you always must initiate a connection from the mobile device, so you cannot use push methods (Internet to Mobile), the mobile device always must pull (data from Internet). Some broadband/cable providers might do the same. Usually you can see this if your ISP hands out an IP in the 10.x.y.z range to you.
There might be another trick how to get the connection working:
Ask your ISP to get some IPv6. Perhaps use 6to4. With IPv6 you eliminate NAT completely, your local LAN then directly interconnects to the Internet on IPv6. Be sure to activate your firewall/iptables on your Intranet host on the IPv6 interface, else you might see Intruders very quickly.
HTH
