Shorewall users - Oct 2003 - Question about MASQ/VPN/One Interface Setup

Hi everyone,
 
while my current setup is working I am wondering if there is any better
and easier config. 
 
My problem is as follows:
 
I have a group of people somewhere in Spain, Greece, Hawaii (where ever
there is sun and blue water) taking pictures for advertising etc. While
they all have notebooks (normally Windows) they now need to have a Linux
or SunOS based machine which will create compressed images of the photo
shoots they did and send them using RSYNC (for now) or another
proprietary protocol to a Sun within a Datacenter. 
 
After selection the adverting company will request a set of picture of
high quality which will be send as a response.
 
Those people should have either 2 B1 Channels (ISDN) or a LAN/WAN
connection above 1 MBit from their hotel rooms. RSYNC and the
proprietary protocol are unsecure by all means so the communication must
be encrypted. The access to the sun must be authorized. While the
Datacenter Sun is secured by a fault tolerant Checkpoint Cluster, we can
use Checkpoint''s IPSEC implementation as it lacks any stable Sun or
Linux client for a Roadworrier configuration (dealing with dynamic
IP''s). As a result we have following setup
 
OUTSIDE LINUX
            |
            |
            V
BAD INTERNET
            |
            |                           -----> INSIDE SUN
            V                          |
CHECKPOINT---> DMZ I--
            |                           |
            |                           -----> Linux/Shorewall/Freeswan
            v
    DMZ II
 
While this looks rather easy there is one problem: The INSIDE SUN''s
default gateway is the Checkpoint and has to be the Checkpoint.
Non-RFC1918 addresses might come in (encrypted) through the Linux FW but
will leave (unencrypted) through the Checkpoint. 
 
The checkpoint will accept IKE and ESP to reach the Linux Firewall/VPN.
The Linux FW has following interfaces ETH0, ETH0:0 and IPSEC0. ETH0 as a
non-RFC1918 address, eth0:0 has a RFC1918 address. The INSIDE Sun will
know to route the RFC1918 address through the Linux FW.
 
My MASQ file looks like this (123.234.111.3 is the IP of the INSIDE SUN)
 
eth0:0:123.234.111.3     ipsec0          10.43.1.1
 
As said, this works just fine, but I would prefer if there would be a
way to hide NAT using the Linux Firewalls external (ETH0) IP address.
This would allow me to skip doing any changes to the SUN (which might be
SUN''s in the future)
 
Anyone any idea ?
 
Axel
 
--------------------------------------------------------------------
Wenn Sie mich suchen, ich halte mich in der N?he des Wahnsinns auf,
genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik,
gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und
Idiotie!
--------------------------------------------------------------------

On Tue, 2003-10-14 at 13:09, Westerhold, Axel wrote:
>  
> Anyone any idea ?
>  
Have you considered SSH tunnels (port forwarding) directly into the
INSIDE SUN box?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Hi Tom,

if I can avoid it I would not. As said, I do not want to touch the Suns
or actually have the Sunnies touch them as soon as they work :-). 

There are a few other issues on this. I would like to limit the access
from unknown IP ranges to IKE and ESP simply because those protocols
have no usability (shell, file transfer protocols etc.) attached per
definition. You can''t open a shell through UDP 500 or protocol 50. This
limits available exploits to password exploits (brute force or guessing
certificates. Also, the Sun''s have a very special configuration. They
might not be Sun''s at all or not all of them might be. 

And the main reason is <g> I can handle MS OS''s,Linux and
sometimes BSD
but I stay away from SUN. As I am the guy reporting on Security I want
this handled through within the team I belong to.

If this means to force routing on the Sun''s, well if needed I will do
it. I was just wondering if there is any way to use the non-rfc IP of my
Linux FW. 


Axel

Tom,

I forgot to mention that to those Click,Clack Picture makers the Linux
box is a blackbox. They have no idea how SSH, IPSEC or TPC/IP work.
Scripting the needed ISDN/LAN/WAN access is easy enough as I did this
already and have the needed templates. I have no idea the impact of
doing it using SSH.

Also, my understanding on SSH tunneling is, that I need to define the
TCP/UDP ports tunneled on the client side. My current solution simply
allows for all kinds of protocols on the client side while it might
reject on the Datacenter side. This allows for easy outside setup
without security issues as I can still limit the inside.

Axel

-----Original Message-----
From: Westerhold, Axel 
Sent: Mittwoch, 15. Oktober 2003 00:05
To: ''shorewall-users@lists.shorewall.net''
Subject: RE: [Shorewall-users] Question about MASQ/VPN/One Interface
Setup

Hi Tom,

if I can avoid it I would not. As said, I do not want to touch the Suns
or actually have the Sunnies touch them as soon as they work :-). 

There are a few other issues on this. I would like to limit the access
from unknown IP ranges to IKE and ESP simply because those protocols
have no usability (shell, file transfer protocols etc.) attached per
definition. You can''t open a shell through UDP 500 or protocol 50. This
limits available exploits to password exploits (brute force or guessing
certificates. Also, the Sun''s have a very special configuration. They
might not be Sun''s at all or not all of them might be. 

And the main reason is <g> I can handle MS OS''s,Linux and
sometimes BSD
but I stay away from SUN. As I am the guy reporting on Security I want
this handled through within the team I belong to.

If this means to force routing on the Sun''s, well if needed I will do
it. I was just wondering if there is any way to use the non-rfc IP of my
Linux FW. 


Axel

On Tue, 2003-10-14 at 15:14, Westerhold, Axel wrote:
> 
> If this means to force routing on the Sun''s, well if needed I will
do
> it. I was just wondering if there is any way to use the non-rfc IP of my
> Linux FW. 
You may be able to define the routes on the CheckPoint and have it send
ICMP redirects to the SUNs when they try to route VPN traffic through
the CheckPoint.

People often do that with Shorewall Boxen judging by the frequency with
which people ask why it''s not working right :-) (usually setting the
''routeback'' and ''newnotsyn'' options on the
local interface gets them
going).

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Hi Tom,

ok :-) Changing anything on a Checkpoint NG/R54 normally is trouble. But
Checkpoint issues are not the topic in here (well  they do a great job
but sometimes they simply are overdoing it). So as a guess I will just
keep with the routing entries. 

Still, thanks for your help and in any case :-) doing the MASQ using
NETFILTER would have made things more difficult then using Shorewall.
Sooo, well done Tom.

Axel


--------------------------------------------------------------------
Wenn Sie mich suchen, ich halte mich in der N?he des Wahnsinns auf,
genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik,
gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und
Idiotie!
--------------------------------------------------------------------

On 14 Oct 2003 at 22:14, Westerhold, Axel wrote:
> 
> Tom,
> 
> I forgot to mention that to those Click,Clack Picture makers the 
Linux
> box is a blackbox. They have no idea how SSH, IPSEC or TPC/IP work.
> Scripting the needed ISDN/LAN/WAN access is easy enough as I did 
this
> already and have the needed templates. I have no idea the impact of
> doing it using SSH.
> 
> Also, my understanding on SSH tunneling is, that I need to define 
the
> TCP/UDP ports tunneled on the client side. My current solution 
simply
> allows for all kinds of protocols on the client side while it might
> reject on the Datacenter side. This allows for easy outside setup
> without security issues as I can still limit the inside.
Why not use something like "unison"?  It works on Windows and Linux
and it can be set up to go over a ssh tunnel, without having the end 
user
know how to do that.  They just put the images in a directory on the 
laptop and click a desktop icon. 

Set up to use ssh, the only port you have to open is ssh, and that
can be automated.

We use this to keep several (windows and linux) laptops as well as 
our Australian office in sync with our server, and it works quite 
well.



-- 
______________________________________
John Andersen
NORCOM / Juneau, Alaska
http://www.screenio.com/
(907) 790-3386

._______________________________________
John S. Andersen
NORCOM  mailto:JAndersen@norcomsoftware.com
Juneau, Alaska
http://www.screenio.com/

Hi John,

well I do not know what unison actually does and it is 1 pm over here I
actually won''t check right now but given your info it assumes the users
computer is the one actually connected. In this case this might or might
not be the case. Normally the user has a notebook with windows and a
Linx/helios system for the pictures which is also the router/VPN system.
Such a linux system has no X or any other GUI installed. Thanks for your
input though. This might be really useful for other projects.

Axel


--------------------------------------------------------------------
Wenn Sie mich suchen, ich halte mich in der N?he des Wahnsinns auf,
genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik,
gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und
Idiotie!
--------------------------------------------------------------------


Why not use something like "unison"?  It works on Windows and Linux
and
it can be set up to go over a ssh tunnel, without having the end user
know how to do that.  They just put the images in a directory on the
laptop and click a desktop icon. 

Set up to use ssh, the only port you have to open is ssh, and that can
be automated.

We use this to keep several (windows and linux) laptops as well as our
Australian office in sync with our server, and it works quite well.



--
______________________________________
John Andersen
NORCOM / Juneau, Alaska
http://www.screenio.com/
(907) 790-3386

._______________________________________
John S. Andersen
NORCOM  mailto:JAndersen@norcomsoftware.com
Juneau, Alaska
http://www.screenio.com/

On 14 Oct 2003 at 23:14, Westerhold, Axel wrote:
> Hi John,
> 
> well I do not know what unison actually does and it is 1 pm over 
here
> I actually won''t check right now but given your info it assumes
the
> users computer is the one actually connected. In this case this 
might
> or might not be the case. Normally the user has a notebook with
> windows and a Linx/helios system for the pictures which is also the
> router/VPN system. Such a linux system has no X or any other GUI
> installed. Thanks for your input though. This might be really 
useful
> for other projects.
> 
> Axel
Well take a look at it when you get time Alex, it might do it for 
you.  It doesn''t need a gui, I run it un-attended with cron jobs
and I run it from desktop icons in both windows and linux.

It''s best set up as a remote push (field Notebook pushes to
central site), but its very flexible and robust.  Under the hood
its running rsync over ssh with a custom directory hashing 
scheme to know which files need to be shipped.  As such,
its imune to time zone issues and clock drift etc.

-- 
______________________________________
John Andersen
NORCOM / Juneau, Alaska
http://www.screenio.com/
(907) 790-3386

._______________________________________
John S. Andersen
NORCOM  mailto:JAndersen@norcomsoftware.com
Juneau, Alaska
http://www.screenio.com/