Re: [Devil-Linux-discuss] DL 1.2 routing problem

[Moray M. <mmc...@ox...>]

SSH is the thing to use for remote administration. Make sure you have given
the root login an unguessable password and that START_SSH is set in the
config file or through the setup script. You could set up other users, but
for a firewall box one would expect root access to make most serious
changes.

You certainly want to make sure that SSH is not permitted from EXT_DEV,
which it isn't in your current firewall ruiles.

When you say crossover cable between eth0 and eth2 cards, I assume you mean
between eth0 on one box and eth2 on another. I'm not sure why you're doing
this. I strongly suggest you disable your eth0 interfaces, disconnect from
the Cisco switch and just work with links between the two eth2 cards via
crossover. Your routing currently shows an awful lot of routes for the
1.4.2.0 network.

As far as routing for the IPSEC tunnels goes, I would start with static
routing, viz. on right side route 172.18.0.0/24 via ipsec0, and conversely
on the left side route 192.168.1.0/24 via ipsec0. You can worry about
dynamic routing later - you wouldn't even need to have dynamic routing
except for the load balancing.

The firewall rules additions I gave you ought to be enough to enable IPSEC
to work - you should at least see connection stuff in the logs when you try
and bring ipsec up...

Yours,
Moray



----- Original Message ----- 
From: "Red Gibbs" <red...@bl...>
To: <dev...@li...>
Sent: Sunday, November 21, 2004 1:04 AM
Subject: RE: [Devil-Linux-discuss] DL 1.2 routing problem


> Moray
> Yes both systems can talk directly to each other.  They are going through
> the ISP Cisco switch which is x.x.x.1.
> I currently have them setup just as you suggested using a crossover cable
> between eth0 and eth2 cards.
> It looks like you have just told me where I need to focus my attention,
the
> "firewall rules".
>
> I believe the firewall.rules are blocking the traceroute because it would
> not work when I tried it earlier.
>
> I was reading some howto's on using ipsec pluto command to setup some
> routing for the tunnels, how does that play into this?
>
> I also saw a how-to that talked about setting up the iptables themselves,
> how do they figure in?
>
> I noticed that I could not use telnet on the systems localhost.
> What would you recommend for a remote administration on these box's?
> Should / could administration be restricted to the root user only?
>
> thanks again
> RG
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf Of
Moray
> McConnachie
> Sent: Saturday, November 20, 2004 4:27 PM
> To: dev...@li...
> Subject: Re: [Devil-Linux-discuss] DL 1.2 routing problem
>
> OK, I won't repeat the whole of your message here. There are several
> problems: one problem is that it looks as though your firewall.rules would
> not let the IPSEC connection happen - have you done any modification of
the
> default rules? - even assuming anything else is right.
>
> Another problem is that the routing looks weird - are your left-hand
server
> and your right hand server really in the same subnet and able to talk to
one
> another directly? What is the output from this server (1.4.2.127) of
> traceroute 1.4.2.135 ? (though traceroute might be caught by
> firewall.rules).
>
> The trouble is there are an awful lot of variables in this kind of setup,
> and no one is going to be able to debug it remotely very easily. Your best
> bet would be to put two Devil Linux boxes each with two interfaces, a
> pretend public one and a private one on a test network. Put their "pretend
> public" interfaces on the same hub and subnet, and see if you can get a
> machine on the private side of one to connect to a machine on the private
> side of the other using IPSEC, initally with no firewall rules. Needs 4
> machines, but they could all be running Devil Linux with no hard drive
> config, and therefore "borrowed" temporarily from elsewhere.
>
> Then you can add in the firewall rules on your test set, and see if it
still
> works. Once that's the case, it is much less hard to move it to the public
> internet, although there you will want to be VERY sure about the security!
>
> Otherwise I fear you may be biting off more than you can chew here. But
> here's some advice on the firewall.rules side of it FWIW. I don't have
> access to a Linux box here, so syntax may occasionally be off.
>
> Just concentrating on iptables, first off, the machines have to be able to
> talk IPSEC to one another: to allow IPSEC, the key traffic ports are udp
500
> and esp 50. On the right hand side - I'm not sure I completely understand
> your setup, so you'll have to check it carefully -
>
> ${IPTABLES} -A INPUT -i $DMZ_DEV -p udp -s 1.4.2.135 --dport 500 -j ACCEPT
> ${IPTABLES} -A INPUT -i $DMZ_DEV -p esp -s 1.4.2.135 --dport 50 -j ACCEPT
>
> On the left hand side, the source would be 1.4.2.127
>
> Secondly you may want for testing purposes to let the machines on the
other
> private subnet talk to your router, so you would do to let them talk to
> everything on the router (risky)
>
> ${IPTABLES} -A INPUT -i $IPSEC0 -s 172.18.0.0/24 -j ACCEPT
>
> with something similar on the left.
>
> Thirdly you have to allow traffic to be forwarded from the two private
nets
> over the ipsec interface: to allow everything across from private subnet
to
> private subnet, on the right hand side you would do the following - though
> this would be more risk than I would take, better to only open up the
ports
> you know you need or can test at this stage (I often use SSH ports for
this
> purpose). Note that anything you use often like a network address would be
> better off being defined as a variable early in the script.
>
> ${IPTABLES} -A FORWARD -i ipsec0 -o $INT_DEV -s 172.18.0.0/24 -d
> 192.168.1.0/24 -j ACCEPT
> ${IPTABLES} -A FORWARD -o ipsec0 -i $INT_DEV -s 192.168.1.0/24 -d
> 172.18.0.0/24 -j ACCEPT
>
> And you need something similar on the left. To restrict it to SSH, you
would
> just add -p tcp to both lines, and for the first line --dport 22 and for
the
> second --sport 22 [THEN I WOULD GET THIS]
> ${IPTABLES} -A FORWARD -i ipsec0 -o $INT_DEV -s 172.18.0.0/24 -d
> 192.168.1.0/24 -j ACCEPT -p tcp --dport 22
> ${IPTABLES} -A FORWARD -o ipsec0 -i $INT_DEV -s 192.168.1.0/24 -d
> 172.18.0.0/24 -j ACCEPT -p tcp --sport 22
>
> Yours,
> Moray
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>