Hi all,

I'm currently having a weird problem with iptables / portforwarding on a debian sarge box running kernel 2.6.8-2 and proxy squid 2.5.

I'm running a network with ~400 pcs in a class b network (172.16.0.0), the linux box has the ip-address 172.16.10.254 assigned to eth1 and an additional interface (which doesn't matter to this case anyways, but I wanted to mention as much as possible) with the ip-address 10.13.13.14 assigned to eth0 (Gateway 10.13.13.254, forwarding enabled).

The 400 boxes are standing in 13 different rooms (it's a school btw) and to give the teachers inside the rooms the possibility to enable or disable the internet-access for the room they're in, I used iptables to forward the requests from the different pcs inside the room from the linux box back to the teacher's pc which runs a windows-based proxy-server that can be enabled and disabled by the user working on the workstation.

- I know it doubles the traffic, but it's not really an option to tell the pcs inside the rooms the ip-address of the proxy running on their teacher's pc because that would be a security leak due to the fact that the students would all to soon know the ip-addresses of the teacher's pcs of all rooms and would start looking for a running proxy if their teacher doesn't want them to use the internet and thereby disables it on the one hand and too much changing around on the image used for a specific pc type on the other hand. (If ADS-Group-Policies did apply to firefox, it would have been way more easy...)

So the line I used to set up this forwarding was the following (example):

iptables -t nat -I PREROUTING -s 172.16.1.51 -p TCP --dport 8080 -j DNAT --to 172.16.1.50:8080

where 172.16.1.51 is a sample-student-workstation, 8080 is the port where the squid runs (but the students shall not reach squid directly) and 172.16.1.50:8080 is the ip-address and port of the teacher's workstation running the JANA Proxyserver on Port 8080 again.

I added and removed the additional parameters like -d 172.16.10.254 and -i eth1 but it had no effect.

Now the problem: This configuration was running for about 3/4 of a Year with a 2.4 Kernel, then the housekeeper called and said "we got a major electricity problem and the electricians are here, you need to shutdown all your PCs immediatly" (UPS isn't an affordable option for German business schools).

After I rebooted the box, it didn't work anymore, but my documentation said "that's all you did" and my memory told me "that's all you did" so I tried around for hours and still got no result so I reinstalled the box in case it would work better with a fresh install and used the distribution with the above mentioned kernelversion this time, but still, the port-forwarding on the single device eth1 doesn't work anymore.

If I disable the iptables-rules, the clients can reach the proxy on 172.16.10.254:8080 w/o problems and if I enter the IP/Port of a teacher's workstation (e.g. 172.16.1.50:8080) into the browser-settings, it also runs fine. I'm also sure, that it's not port-forwarding in general, that fails, because I can for example make the student's pcs reach any machine/port inside my DMZ with the line

iptables -t nat -I PREROUTING -s 172.16.1.51 -p TCP --dport 8080 -j DNAT --to 10.13.13.11:80

and it works fine, and I'm also able to use the proxy in a teachers room from an outside pc, like with this line

iptables -t nat -I PREROUTING -s 10.13.13.13 -p TCP --dport 1337 (or 8080, it doesn't matter) -j DNAT --to 172.16.1.50:8080

So my obvious guess is a problem with forwarding ports on a single device, but I can't figure out how to fix it...

If you got any ideas regarding this issue, I would me more than grateful as this is bugging me for the third week now and I think I nearly tried everything but it looks like I'm working on the wrong spot...

Thanks for you help in advance.

Hello,

I was wondering how your clients actually access the teacher's proxy. How is there browser setup under connections? Do you have the IP of the Debian/Squid box and Squid port as part of their proxy configuration?

Other than that I can only dare to say that your problem is not the port forwarding or the underlying configuration of iptables. I would check to see how your JANA proxyserver is responding to the forwarded packets. Sometimes some proxies don't like the packets that have been somehow manipulated or altered during their trip (like redirections and NATs). My guess is that JANA is dropping the HTTP requests for some reason. I personally have never used that proxy server, but I'm sure the logs of it should give you some clue.

If you can post the JANA server logs, I'd be glad to continue to help.

Good luck.

The Clients all have entered the IP and Port of the Debian box entered as their Proxy (172.16.10.254:8080) - for IE as part of the Group Policy and for Mozilla Firefox as part of the Mandatory Profile I'm using. The JANA-Proxy Log showed no entries within the time when the iptables-rules were active but normal traffice coming from the Clients the moment I entered it's address manually into a Client-Firefox (e.g. Client on 172.16.1.51, Proxy on 172.16.1.50:8080) and again (obviously) nothing at all when the rules were not active and the clients were using the Debian box as their proxy.

To make sure it wasn't just a problem with one of the proxies I also connected to 172.16.10.254:8080 and 172.16.1.50:8080 via Telnet. The Jana responded correctly to a Telnet request when I connected directly, same did the Squid when I was connecting to 172.16.10.254:8080 without the rules being active. The moment I applied the rules, the request was stuck.

To have another test on the internal Port-Forwarding, I made the up the follwing rules:

iptables -t nat -I PREROUTING -p tcp -s 172.16.1.51 --dport 8080 -j DNAT --to 172.16.12.33:80

and

iptables -t nat -I PREROUTING -p tcp -s 10.13.13.13 --dport 8080 -j DNAT --to 172.16.12.33:80

where 172.16.12.33 is another box that runs a webserver.

Coming from 10.13.13.13, the request was forwarded correctly and I had the website up. Coming from 172.16.1.51, the request was stuck again (no matter if with proxy entered or not), so I'm expecting the problem in the routing on one device...