IRC DCC between 2 clients on the same net.
I have 2 clients behind a masquerading gateway.
When one of them DCC SEND to the outside world, everything's fine. (Thanks
to ip_conntrack_irc/ip_nat_irc)
But when I DCC-SEND from one client to the other client on the same network, it doesn't work. The sending side fails almost immediately.
Is this normal?
I'm using kernel 2.4.17.
Quoted 11 lines
I have 2 clients behind a masquerading gateway.
When one of them DCC SEND to the outside world, everything's fine. (Thanks
to ip_conntrack_irc/ip_nat_irc)But when I DCC-SEND from one client to the other client on the same network, it doesn't work. The sending side fails almost immediately.
Is this normal?
I'm using kernel 2.4.17.
DCC is a passive protocol so sending a file means an inbound tcp connection, why you need the irc modules in the first place. What is happening is that ip_nat_irc has little choice but to substitute the external ip of your gateway for your LAN ip in the DCC SEND request, thus making the other client think it should connect to your gateway instead of the LAN address of the client machine to get the file -- what you want if the other client is outside your firewall. ip_nat_irc then intercepts this and forwards the connection to the LAN ip making to DCC SEND request.
Try unloading the two irc modules and attempting a SEND, which should work if the two LAN computers can connect to each other. Also, make sure the rules in the FORWARD chain of the gateway box allow connections to the external ip from you LAN.
-Bob
Thanks for the reply.
Quoted 21 lines · Bob Hockney
Quoted 11 lines
I have 2 clients behind a masquerading gateway.
When one of them DCC SEND to the outside world, everything's fine. (Thanks
to ip_conntrack_irc/ip_nat_irc)But when I DCC-SEND from one client to the other client on the same network, it doesn't work. The sending side fails almost immediately.
Is this normal?
I'm using kernel 2.4.17.DCC is a passive protocol so sending a file means an inbound tcp connection, why you need the irc modules in the first place. What is happening is that
ip_nat_irchas little choice but to substitute the external ip of your gateway for your LAN ip in the DCC SEND request, thus making the other client think it should connect to your gateway instead of the LAN address of the client machine to get the file -- what you want if the other client is outside your firewall.ip_nat_ircthen intercepts this and forwards the connection to the LAN ip making to DCC SEND request.
Quoted 2 lines
Try unloading the two irc modules and attempting a SEND, which should work if the two LAN computers can connect to each other. Also, make sure the rules in
Yes, unloading the two irc modules does work. But, that means I have to manually unload the modules when I'm sending to LAN computer, and load it again when I want to send to outside world. Surely there must be an easier way to support both cases.
Quoted 2 lines
the FORWARD chain of the gateway box allow connections to the external ip from you LAN.
Why FORWARD? Shouldn't it be the INPUT chain?
Anyway, I tried it with default policy of INPUT/FORWARD/OUTPUT set to "ACCEPT", it didn't work.
Quoted 4 lines · Jihoon
Quoted 2 lines
the FORWARD chain of the gateway box allow connections to the external ip from you LAN.
Why FORWARD? Shouldn't it be the INPUT chain?
I meant INPUT. My bad.
Quoted 8 lines
Quoted 8 lines
DCC is a passive protocol so sending a file means an inbound tcp connection, why you need the irc modules in the first place. What is happening is that
ip_nat_irchas little choice but to substitute the external ip of your gateway for your LAN ip in the DCC SEND request, thus making the other client think it should connect to your gateway instead of the LAN address of the client machine to get the file -- what you want if the other client is outside your firewall.ip_nat_ircthen intercepts this and forwards the connection to the LAN ip making to DCC SEND request.
After attempting this, the problem is that the client receiving the file attempts a connection to the external ip, which is intercepted by ip_nat_irc and forwarded to the other client on the LAN, but with a source ip of client initiating the tcp connection, which is correct (it would be the ip of the a remote host if outside the firewall). The second client then responds, but since it is responding to an ip on its own subnet, the reply doesn't go through the gateway. The first client is expecting a reply from the external ip (since it sent the SYN there), but gets a reply from another ip and rejects it. The second client immediately closes the DCC connection, while the first continues to wait for a reply until it times out.
This behavior is normal, by design in ip_nat_irc, and difficult to fix. One workaround, which does work, is modify the routing table of both clients to send all LAN traffic through the gateway. A kludge at best.
-Bob
Quoted 11 lines · Bob
After attempting this, the problem is that the client receiving the file attempts a connection to the external ip, which is intercepted by
ip_nat_ircand forwarded to the other client on the LAN, but with a source ip of client initiating the tcp connection, which is correct (it would be the ip of the a remote host if outside the firewall). The second client then responds, but since it is responding to an ip on its own subnet, the reply doesn't go through the gateway. The first client is expecting a reply from the external ip (since it sent the SYN there), but gets a reply from another ip and rejects it. The second client immediately closes the DCC connection, while the first continues to wait for a reply until it times out.
Quoted 3 lines
This behavior is normal, by design in
ip_nat_irc, and difficult to fix. One workaround, which does work, is modify the routing table of both clients to send all LAN traffic through the gateway. A kludge at best.
I see. Thanks.
Guess there is no clean solution for this situation.
when ip_nat_irc intercepts the dcc connection, can't you make it change the source ip to the gateway's ip? That way, responding client would send the packet to gateway where the dst ip would be changed back to the original one ? Just a thought.. I don't know much about the netfilter nat structure.