All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.