View Single Post
  #4   (View Single Post)  
Old 13th June 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 6,231
Default

Congratulations. You have a user who is operating a NAT router, just like you are. Yours is OpenBSD with PF, his is Windows with ICS.

All of the traffic routed through his workstation will appear to come from it, or be destined for it. However, the Time-To-Live (TTL) value may be greater than 1. The TTL may be greater than 1 for traffic that isn't going to or coming from his private network, also. This is not a guaranteed way to differentiate.

You would have to implement a Deep Packet Inspection facility, and even then, you may still have difficulty differentiating between workstation-specific traffic and traffic routed through it.

For inspecting the contents of the packets, which PF does not do, OpenBSD has relayd(8). This might offer a partial solution. See reyk@'s paper from last year on recent advances in the tool, and the relayd.conf(5) man page for the scope of the analysis it can perform.

You are entering an "arms race" with your user. If you make changes to attempt to block his private network but not his workstation -- such as setting TTL to 1 for all traffic destined to it -- he can circumvent those kinds of restrictions. All he needs is Google, or Bing, and a little time.

If you cannot control your user -- such as having him agree to approved encryption and security on his wireless network, and approved devices to connect, you have two more options:

1. Block traffic between his workstation and the rest of the LAN by placing it in its own subnet, and do not permit traffic to route between the subnets.
If you are sharing the same Ethernet segment, you can block IP packets on the LAN this way, however you cannot block non-IP Ethernet frames. With an alias address on your router's NIC, he and his network can reach the Internet but not any other IP device on your LAN.
2. Block him entirely.

Last edited by jggimi; 13th June 2014 at 10:14 PM. Reason: clarity
Reply With Quote