Re-routing TCP packets

Home Forums Discussions Support Portal Re-routing TCP packets

This topic contains 20 replies, has 4 voices, and was last updated by  fitland 14 years, 10 months ago.

Viewing 6 posts - 16 through 21 (of 21 total)
  • Author
    Posts
  • #5535

    Voxen
    Participant

    Hi bk, yes I see what you mean.

    Okay I’ll try to explain what I try to achieve.
    I’m writing an antispam application that runs as a local POP3 proxy server, standing between the mail client and the remote server. I want to avoid the user all the complexity of modifying his mail client’s account settings to point to the POP3 proxy, so I want to transparently reroute outgoing packets to remote server to the local POP3 proxy. Then the POP3 proxy establishs the real connection to the remote server, grab new mails, filter them and reply to the mail client through the rerouted connection. The mail client needs to believe he’s connected to remote server while he’s actually connected to the local POP3 proxy.

    So we have:

    User PC @ 127.0.0.1
    – mail client (Outlook, etc)
    – POP3 proxy (server listening on port 110)
    – winpkfilter packet router

    POP3 host @ http://www.xxx.yyy.zzz

    When the winpkfilter packet router detects a connection 127.0.0.1 < -> http://www.xxx.yyy.zzz / 110, he’ll change the destination IP and port to local POP3 proxy.

    BTW, about my prior message :

    PCA -> SYN -> PCB
    PCA < - SYN/ACK <- PCB
    PCA < - SYN/ACK <- PCB
    PCA -> RST -> PCB (ZeroWindow)

    I ran this between 2 PCs in my local network. I’ve never been to make it work on the same machine as I’d like to according to this message.

    #5536

    bk
    Participant

    Well, winpkfilter isn’t perfectly suitable to your needs, but you can work around the problems to make it work.

    You can’t work with 127.0.0.1 packets, but you can simulate a “fake” host sending packets to your POP3 proxy. When the mail clients starts a connection, the PC will generate packets on the network adapter you use to connect to the internet or LAN. You can catch those packets, and send them back in. To do so, you must “simulate” a host on the same net your adapter is connected to. Suppose you are using an ethernet adapter with IP address 192.168.0.10, then outgoing packets will exit with that source IP. You must then change:

    ORIGINAL:
    source: 192.168.0.10
    destination: POP3 IP

    CHANGED:
    source: a fake IP on the same net, i.e. 192.168.0.100
    destination: must be your IP on that adapter / network, in our example 192.168.0.10

    Recalculate the checksums, and send the new packet back to windows, dropping the original.

    Now windows should think that an external PC is sending packets, and will reply to that (fake) IP. You must catch outgoing packets with the fake destination, and send them back in reversing what you’ve done in the previous step:

    ORIGINAL:
    source: 192.168.0.10
    destination: 192.168.0.100 (fake)

    CHANGED:
    source: POP3 IP
    destination: 192.168.0.100

    Recalculate the checksums.

    #5537

    Voxen
    Participant

    I’m running to try that. It makes sense, hope it gonna work 🙂

    Thanks again for your great advices!

    #5538

    Voxen
    Participant

    2 questions following your post:

    a) what about the destination MAC address?
    If I’ve understood what you said, I guess it is:
    ORIGINAL:
    source: 192.168.0.10
    destination: POP3 IP
    MAC source: MACA
    MAC destination: MACB

    CHANGED:
    source: a fake IP on the same net, i.e. 192.168.0.100
    destination: must be your IP on that adapter / network, in our example 192.168.0.10
    MAC source: MACB
    MAC destination: MACA

    b) do I send the modified packets to Adapter or MSTCP?

    #5539

    bk
    Participant

    @voxen wrote:

    a) what about the destination MAC address?

    If I’ve understood what you said, I guess it is:
    ORIGINAL:
    source: 192.168.0.10
    destination: POP3 IP
    MAC source: MACA
    MAC destination: MACB

    CHANGED:
    source: a fake IP on the same net, i.e. 192.168.0.100
    destination: must be your IP on that adapter / network, in our example 192.168.0.10
    MAC source: MACB
    MAC destination: MACA

    Well, you must try.. Since you are simulating a fake host, you should also fake its MAC address. But this could lead to problems with your ARP table (the system table that the OS keeps to know how to link an IP with a MAC address), depending on how the OS works. The best bet here is to use MACB as source and MACA as destination, as you guessed. Again, you must try because your OS might decide that the source IP is not correct for that source MAC and drop the packet. This should not happen, btw.

    The MAC address is the same as the IP address but on a lower level. Each host on an ethernet has a MAC address, which is associated with an adapter. MAC addresses are limited to the local ethernet the adapter is connected to and have no meaning on other networks. When the OS must send a packet, it checks the destination IP address and using the routing table it discovers the next host (hop) on the path of the packet, the network to use and its adapter on that net. Notice that the destination address of the packet is not always the same as the destination of the next hop along the path. As an example, if you have a local net connected to the internat through a gateway, and your host is trying to send a packet to http://www.microsoft.com, the destination IP address on the packet is the IP of http://www.microsoft.com, but the destination IP of the next hop is the IP of your gateway. So to send that packet to microsoft, your host sould know that it must send the packet to the gateway and not to the real destination. The gateway will then send the packet to the real destination. As another example, if the destination of the packet is instead on a net the host is directly connected, then it can send the packet directly to the destination host. All this informations can be found in the routing table of the OS, which links each host IP address, or network IP address, with an adapter / network and if present with a gateway. So using this table your OS knows the next host on the path and the adapter to use.
    Now it must send the packet to this host (next hop), that can be the real destination or a gateway. Since the next hop can only be on a local net, it only needs the lower level address of the hop, since lower level protocols don’t understand IP addresses. There is a standard way to do so, it’s the ARP table. This table is keept by the OS using a standard packet exchange with other local hosts on the nets it’s connected to. It can also contain static entries, that are inserted by the users and not discovered using the ARP protocol.
    Btw, the ARP table links each IP address with the MAC address of a host on a local net. So using the ARP table the OS can know the MAC address of the next hop of the IP address. The packet is then incapsulated in a lower level packet (the ethernet packet) with the correct destination MAC address.
    Each host on an ethernet listens each packet send, but sends the packet to the OS only if the destination MAC address is its MAC address on that adapter.

    That’s roughly how it works. Notice that’s correct only for ethernets and similar networks.

    b) do I send the modified packets to Adapter or MSTCP?

    Normally you modify the packets and send them along their normal path:

    You receive an outgoing packet from MSTCP, modify it, and send it to the adapter.
    You receive ad incoming packet from an adapter, modify it, and send it to MSTCP.

    BUT there are other special cases, sugh ad modified routing behaviour, which might require to send a packet from an adater to another, or, as in your case, to send a packet from MSTCP to MSTCP again.

    In your case, you catch outgoing packets, and send them back modified to MSTCP. Notice that you must not do this to ALL packets, or you will block normal network traffic. You must reroute only the correct packets (i.e. the packets with the IP address, protocol type, and TCP port you need to reroute).

    So, to make it short, you will receive packets from MSTCP, and must send them back to MSTCP.

    #5540

    fitland
    Participant

    Voxen, where you able to perform what you want? I have a similar need.
    (I’ve also to integrate with wireless technologies)

    Thank you
    Marco

Viewing 6 posts - 16 through 21 (of 21 total)

You must be logged in to reply to this topic.