|
Hi,
Sorry for lengthy e-mail. But, please, read on, it may worth it.
I'm trying to find a solution for making Microsoft ActiveSync to work through my Linux firewall. ActiveSync is used for synchronization between a desktop computer running ActiveSync agent and a Windows CE device. This synchronization is possible in numerous ways, including through a TCP/IP connection. In essence, the client (Windows CE device) opens a TCP connection to the server on port 5678. The server, in its turn, opens a connection back to the client port 990.
How it can be supported with Netfilter? For my understanding, with no NAT, just port 990 should be kept open to inbound TCP connections. When NAT is used, it's still solvable through DNAT if the IP address of the Windows CE device is known in advance. The question is how to solve this when Windows CE obtains its IP address through DHCP. I looked extensively through Netfilter docs but failed to find anything useful. Did I miss something?
Here, Port Triggering can come to my rescue. Port Triggering is a popular extension found on some consumer-grade hardware routers (including some Linux-based ones). In essence, it allows opening (and correct DNAT-ing, if necessary) of certain inbound firewall ports if some outbound activity on some other ports has been seen from within the private network. This functionality is somewhat similar to non-passive FTP. The difference is that outbound packet analysis is not required for determining the correct inbound ports, but instead these ports are simply known in advance. As you can see, this makes perfect solution for my ActiveSync problem.
Why Port Triggering is so useful? First of all, even without NAT, or with NAT and static client IP address, it still provides better firewalling solution because it doesn't just keep port 990 open to everybody, but only to the packets related to a previously opened outbound connection to a certain machine. This alone is already a big advantage, since it improves firewall security. Second, it provides a solution for NAT + dynamic client IP situations, which I currently was unable to find with Netfilter.
Finally, my last question, does it make sense to add a support for Port Triggering to Netfilter? Basically, I thought about the following: 1. The incoming packets on the triggered ports should be recognized as RELATED instead of NEW when appropriate. This will make dealing with them exactly the same as incoming FTP data connections, which are, in most cases, allowed. 2. For definition of the inbound triggered ports, I suggest the following new target:
TRIGGER --triggered_port (--tport) Ports that can be triggered. Can be either single number, comma-separated list or colon-separated range. Mandatory. --triggered_protocol (--tprotocol) Protocols that can be triggered - defined identically to all other places where protocol definitions can appear. Default is "all". --triggered_destination (--tdestination) Destination IP. Can be used with usual IP stuff (bits and masks). Default: source IP of the matching packet (before NAT translation, if occurred). --triggered_source (--tsource) Source IP. Can be used with usual IP stuff (bits and masks). Default: destination IP of the matching packet. --trigger_timeout (--ttimeout) Maximum time interval from when the matching packet was seen during which the incoming packet is expected. I currently have no clue what the good default value should be.
I think this covers pretty well Port Triggering needs.
What do you think?
Thanks,
Michael. ________________________________________________________________________ This email has been scanned for all viruses. Mercury Interactive Corporation Optimizing Business Processes to Maximize Business Results http://www.merc-int.com ________________________________________________________________________ |
