All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John A. Sullivan III" <john.sullivan@nexusmgmt.com>
To: Jason Opperisano <opie@817west.com>
Cc: Netfilter users list <netfilter@lists.netfilter.org>
Subject: RE: NAT issues on a VPN tunnel
Date: Wed, 03 Nov 2004 05:48:07 -0500	[thread overview]
Message-ID: <1099478887.2042.8.camel@localhost> (raw)
In-Reply-To: <1099449815.3181.3.camel@hubcap.ljm.dom>

On Tue, 2004-11-02 at 21:43, Jason Opperisano wrote:
> On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote:
> > I believe that would cause a problem on the VPN tunnel as the endpoints
> > won't match. This would need to be done on the far end (site b). 
> 
> believe what you want--it works for me.
<snip>
It can be made to work from either side.  Isn't the tunnel end point the
public address of the gateway? Unless you mean that the internal 
network addresses of the IPSec Security Policies would not match.  I
would think that is true but I have never tried it; it sounds like Jason
has.  Jason, has your solution worked with IPSec?

I have generally found it easier to NAT at the side where the conflict
is being resolved especially if the conflicting network needs
connectivity to several gateways.  Moreover, it presents no SP
problems.  I have designed set ups where the NAT is done on the other
side as Jason suggests and with IPSec in the case where the admin did
not have control over the remote side but it is a little more
complicated - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 



  reply	other threads:[~2004-11-03 10:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03  0:35 NAT issues on a VPN tunnel Christopher Lyon
2004-11-03  2:43 ` Jason Opperisano
2004-11-03 10:48   ` John A. Sullivan III [this message]
     [not found]   ` <CARBONunxtkVO4alvoN00002350@carbon.netsvcs.com>
2004-11-03 15:49     ` Jason Opperisano
2004-11-05  6:42       ` Chris Lyon
2004-11-05 10:40         ` John A. Sullivan III
2004-11-05 16:44           ` Chris Lyon
2004-11-05 16:57             ` Jason Opperisano
  -- strict thread matches above, loose matches on Subject: below --
2004-11-02 15:40 Chris Lyon
2004-11-02 16:09 ` John A. Sullivan III
2004-11-02 17:02   ` Chris Lyon
2004-11-02 18:49     ` John A. Sullivan III
2004-11-02 20:05       ` Chris Lyon
2004-11-03  0:27         ` John A. Sullivan III
2004-11-03  0:24 ` Jason Opperisano
2004-11-03 15:06 ` Michael Gale

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=1099478887.2042.8.camel@localhost \
    --to=john.sullivan@nexusmgmt.com \
    --cc=netfilter@lists.netfilter.org \
    --cc=opie@817west.com \
    /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.