Hello again Kim,
So, this is your network, correct?
+------------------+ 212.202.108.160/27 +--------+
192.168.1.160/28 --+eth2 eth1+-- 192.168.0.0/24 ------+ router |
$DMZ_NET | | $QSC_NET +--------+
| linux |
| | +--------+
192.168.1.176/28 --+eth3 eth0+-- 192.168.141.160/27 --+ router |
$ITX_NET +------------------+ (Arcor) +--------+
: Well, not so fast ... I'm still having some problems, but I fear that
: they will be very hard to solve!
Maybe...but maybe not....
: We have 2 connections, our cheap (Arcor, dynamic IP) and our expensive
: (QSC) with 32 public addresses. Since my company is also linked up to
: a second company using a set of private addresses, we have to use the
: 192.168.1.160/27 net internally, with a DHCP server.
: Most of our traffic must go via the Arcor connection, while
So, in this case, I'd make Arcor the default route in table main, as you
have done.
: all mail will go via the QSC together with SSH to specific machines.
So, MAIL=25 (but could be anything):
for internalnet in $ITX_NET $DMZ_NET ; do
iptables -t mangle -I PREROUTING -p tcp -s $internalnet \
--dport $MAIL -j MARK --set-mark $FWMARK
for ssh_server in $SSH_HOSTS ; do
iptables -t mangle -I PREROUTING -p tcp -s $internalnet \
-d $ssh_server --dport 22 -j MARK --set-mark $FWMARK
done # -- end of ssh_server loop
done # -- end of internalnet loop
: For incoming traffic, all addresses in our 32 public IP numbers, must
: be routed 1-1 for the internal net, so it is possible to make external
: connections to either mail, web, ssh, etc. on internal machines.
No problems...as long as the connections are initiated from the outside,
connection tracking will do the work of transforming addresses for you.
This is one of the big benefits of using netfilter--the connection
tracking mechanisms can make complex scenarios much easier. You should be
able to use the MASQUERADE target on the outbound connections through
Arcor, which gets you connection tracking for anything initiated from
either of your inside networks.
I would, however, recommend adding the following to your RPDB (I assume
you will continue your convention--using an fwmark corresponding to the
table ID of the routing table):
# ip rule add from 212.202.108.160/27 table 1
This should ensure that traffic with an outgoing IP in this range is
transmitted via the QSC default route.
: Now my question is, is it possible to make a destinction for packets
: coming from our internal nets, whether it is part of a connection from
: QSC or from Arcor? So far, I am lost when it comes to ideas and
: plans... It appears like SNAT is impossible as I don't know whether it
: will correctly translate the packet back, and MASQUERADE doesn't seem
: like the solution either!
:
: Using MASQUERADING, it is possible to have traffic running normally via
: the Arcor net, but once we wish to include QSC in the calculation - I
: keep hitting my head on the wall.
Don't hit your head on the wall, Kim--this is linux!
Let us know if the above suggestion(s) help you get split access working
correctly.
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
