[afnog] POP3 Emails Download Behind A Firewall Problem

[Brian Candler]

On Fri, Dec 23, 2005 at 11:54:34AM +0300, tech at cert.co.ug wrote:
> I have a SuSe 9.3 Linux server sitting between my LAN and a Wireless
> Router. The firewall is enabled and the squid proxy is also on. The
> Wireless Router is hooked on to the ADSL device. Ports 53, 25, 80, 110 are
> open on the firewall. I have a set of users with laptops with wireless
> connectivity using the wireless router to connect to the internet. They
> don't go through the Linux proxy server. These users can send/receive
> their POP3 emails. The other set of users on the LAN connect via the Squid
> Proxy. These users can not send/receive their POP3 emails. The linux box
> is running DNS and DHCP for my LAN users. I would like my LAN users to
> send/receive POP3 emails currently sitting in one of our ISP's servers.
> 
> Any suggestions?

First, let me see if I understand rightly - a diagram helps a lot. Is this
what you have?

          ethernet                ethernet   \|/
            LAN 1                  LAN 2      |     ADSL
      ------------------ SuSE -------------- WRT ---------> Internet
                    eth1      eth0

Filling in this diagram with actual IP addresses and the IP configuration of
your SuSE box would help.

Now, from your description I'm guessing at the moment your SuSE box is not
doing any IP routing. Users on LAN1 can connect to services on the SuSE box
(like Squid), and processes on the SuSE box can connect to the Internet, but
people on LAN1 cannot ping people on LAN2 or the Internet. Correct?

If so, you have two main ways to proceed.

(1) Carry on with the proxy approach you are using. Since squid only proxies
http and ftp, you need a way to proxy arbitary TCP sessions.

To do this, install a SOCKS daemon on the firewall, and configure all your
clients on LAN 1 to use this SOCKS proxy. (I expect this setting is buried
in the Windows IP configuration somewhere, but don't ask me where :-)

Then when a client wants to open a TCP connection to pop3.example.net:110,
what actually happens is:

- the client opens a TCP connection to the SOCKS proxy on the firewall
  (normally on port 1080)
- the client sends a request saying 'please open a TCP connection to
  pop3.example.net:110'
- the SOCKS proxy opens a TCP connection from itself to pop3.example.net:110
- the SOCKS proxy copies data back and forth between the two TCP connections

This is actually a pretty good way to build a firewall, and continues your
existing security model of 'no direct IP forwarding' on the SuSE box. The
downside is that all the clients on LAN 1 need to be configured to use the
proxy (just as you currently need to configure them to use the squid proxy
for http). This should be a one-off change though.

There's just one thing you need to ensure for security: that the SOCKS proxy
is configured only to allow requests from LAN1 IP addresses. (Otherwise,
someone on LAN2 or the Internet could connect to your SOCKS proxy and ask it
to connect to machines on LAN1).

(2) Change to using IP routing.

In this case, you turn on IP forwarding on the SuSE box, so that machines on
LAN2 can send packets directly to and from machines on LAN1 (including the
WRT).

The exact details of this depend on how you have your IP addressing set up,
but you'll likely need a static route on the WRT box so that it knows that
the IP addresses on the LAN1 address block are reached via the SuSE box.

Once you have turned on IP forwarding, however, your firewall is not much of
a firewall any more, just a router. You would then need to configure packet
filtering rules to apply policies such as "machines on LAN1 can make
outbound connections to machines on LAN2 or the Internet, but not vice
versa".

Configuring a firewall like this and making it *genuinely* secure is
actually very hard. The benefit of this approach is that the clients on LAN1
can directly access services on the Internet without any configuration
changes, as long as they point defaultroute at the SuSE box.

This may be a reasonable approach for you if there's no need to separate
users on LAN1 and LAN2 into different security zones, and the WRT is acting
as your main and only firewall and you trust it in that role.

If LAN1 needs to be much more secure than LAN2, or you need to protect
machines on LAN1 from attack from LAN2, or protect machines on LAN1 from the
Internet to a higher degree of confidence than just the WRT by itself offers
you, then the SuSE box needs to be a "real" firewall. In that case, you may
be happier using the SOCKS approach as it involves less changes to your
existing firewall and it maintains your existing security model.

Hope this helps,

Brian.