From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] custom route for forwarded traffic
Date: Tue, 30 Oct 2007 16:14:39 +0000 [thread overview]
Message-ID: <4727586F.3030808@riverviewtech.net> (raw)
In-Reply-To: <472741D4.4050409@krediidiinfo.ee>
On 10/30/07 09:38, Aleksander Kamenik wrote:
> I have two networks, users and servers connected via vpn (ipsec). Both
> internal networks. The routing is fine and connections work both ways.
>
> Accordingly both networks have a firewall each which faces the internet
> and they create the vpn link between each other. Both firewalls have
> only one external IP (if they had more, I wouldn't be asking).
>
> The servers network's firewall however does DNAT too. This is for
> external clients who connect to the external IP of the firewall and so
> can connect to the internal mail and webserver.
>
> I want the computers in the users network to connect to the external IP
> of the servers firewall AND have the connection go through the VPN.
>
> If I add a rule to the main routing table in the users network's
> firewall for servers network's external IP to go through the VPN, I will
> break the VPN connection (kind of like the chicken and egg problem).
>
> So I need to create a route, which will apply only for forwarded
> connections. How do I do that?
It has been a long time sense I messed with IPSec under Linux so I can
not say any thing for sure. But what I can say is the direction that I
would start looking.
+----------+ +----------+
(LAN 1)---+ Router 1 +---(INet)---+ Router 2 +---(LAN 2)
+----------+ +----------+
I would only encrypt traffic that is from / to LAN 1 and to / from LAN 2
through the IPSec VPN. Any other traffic from / to LAN 1 that is not
going to / from LAN 2 would be unencrypted and vice versa for LAN 2.
This way when LAN 1 tried to access the external IP of Router 2 it would
not match your routing rules for encryption and thus not be encrypted.
If the traffic is not encrypted it should be subject to the normal DNAT
rule(s) on Route 2. Likewise for reverse traffic and the corresponding
traffic from LAN 2.
I'm not sure how to set up such routes with current IPSec
implementations so I can't help specifically with that. What I do see
is the various types of traffic that will be seen from each end.
LAN 1 <-> LAN 2 (encrypted via IPSec VPN)
(LAN 1 subnet to LAN 2 subnet)
LAN 1 <-> INet (unencrypted)
(Router 1 external to INet)
LAN 1 <-> Router 2 (unencrypted)
(Router 1 external to Router 2 external)
INet <-> Router 1 (unencrypted)
(INet to Router 1 external & DNATed in)
The same above is true in reverse for LAN 2. So in short, I see four
classes of traffic at each connection.
I hope this helps clear things up and make the water a little less
muddy. If you need any thing else, I'll be glad to try.
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2007-10-30 16:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 14:38 [LARTC] custom route for forwarded traffic Aleksander Kamenik
2007-10-30 16:14 ` Grant Taylor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4727586F.3030808@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.