Re: [fw-wiz] VPN Gateway And Nat

From: Dave Mitchell (
Date: 02/25/03

  • Next message: Small, Jim: "[fw-wiz] TCP/IP filtering concepts presentation"
    From: Dave Mitchell <>
    To: Fredrik Lindström <>
    Date: Tue, 25 Feb 2003 11:20:56 -0700

    Correct. I'm not familiar with any products that allow for the actual IPSec termination
    device to be natted. As far as I was concerned it was presented as a means to help RAS
    or spoke VPN sites create a tunnel to a hub site if they are natted. Would cause authentication
    to fail due to the outer IP header being modified on the return trip.

    The Cisco VPN3000 supports both TCP and UDP re-encapsulation in order to perform this, but
    it's obviously not a standard and you need to use their client to do it. Netscreen does it
    also, but with their client. Most vendors use a mode configuration type of IKE with vendor
    ID's in the payloads in order to verify it is their equipment on the remote end.

    If the hub site was natted too, you would get the following during IKE:

    Client Side:

    sends packet:

    [public_nat_ip[udp10000].[rfc1918_ip].[udp500][ikePayload] -> vpn_gateway_ip

    Server Side:

    router_does_nat -> client_public_IP -> vpn_gateway_rfc1918ip

    The IPSec device would now inspect the initial IKE datagram, and depending on how the
    IPSec/NAT implementation is done (usually some sort of aggressive/mode config) and would
    try to reply to the client on the desired UDP or TCP port, but when the router performs
    outbound NAT for the VPN gateway again, it would modify the outer header and source port
    thus causing the connection to fail.

    Correct me if I'm wrong. The whole double nat thing get pretty bulky to put out in ASCII
    properly. :)

    I'd suggest just adding a subinterface on the router (assuming you don't have anymore ports)
    and route public space to the outside of the VPN device. If the VPN device doesn't do
    firewalling also, I'd hang the VPN device off of a DMZ port of your firewall.


    On Sat, Feb 22, 2003 at 10:39:50PM +0100, Fredrik Lindström wrote:
    > Hi,
    > I guess you're using Check Point products (VPN-1 Pro/Net) since you say you
    > use SecuRemote.
    > The configuration you describe is not supported in a Check Point enviroment,
    > the VPN Gateway must always have a public IP address.
    > Regards
    > Fredrik
    > > From: LE CORVIC Y InfoEdpEtcDep <>
    > > To: "''"
    > <>
    > > Date: Fri, 21 Feb 2003 16:44:47 +0100
    > > Subject: [fw-wiz] VPN Gateway And Nat
    > >
    > > Hi All,
    > >
    > > I have a slight problem with a VPN configuration, and wanted to know if
    > you
    > > all can help. Basically, here is the situation :
    > >
    > > PROTECTED_NET-------VPNGATEWAY --------ROUTER-----ClientSecuremote
    > >
    > > The public IP Adress of the VPN GATEWAY is natted at the ROUTER, so that
    > the
    > > ClientSecuremote doesn't access the real IP Adress of the VPNGATEWAY, but
    > > one on the ROUTER.
    > >
    > > The intiation sequence works, and the authentication as well, be when the
    > > network topology is downloaded, no access is possible on servers of the
    > >
    > > I suspect that after topology download, the real IP Adress of the gateway
    > is
    > > given to ClientSecuremote, which uses it for the remaining of the
    > > communication.
    > >
    > > Is there a way to go around that problem, or is it a lost cause... ?
    > >
    > > Thanks for your help.
    > > *************************************************************************
    > >
    > > Ce message et toutes les pieces jointes (ci-apres le "message") sont
    > > confidentiels et etablis a l'intention exclusive de ses destinataires.
    > > Toute utilisation ou diffusion non autorisee est interdite.
    > > Tout message electronique est susceptible d'alteration.
    > > La SOCIETE GENERALE et ses filiales declinent toute responsabilite au
    > titre de ce message s'il a ete altere, deforme ou falsifie.
    > >
    > > ********
    > >
    > > This message and any attachments (the "message") are confidential and
    > > intended solely for the addressees.
    > > Any unauthorised use or dissemination is prohibited.
    > > E-mails are susceptible to alteration.
    > > Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall
    > be liable for the message if altered, changed or falsified.
    > >
    > > *************************************************************************
    > >
    > > --__--__--
    > >
    > _______________________________________________
    > firewall-wizards mailing list
    firewall-wizards mailing list

    Relevant Pages

    • RE: NSLOOKUP: Office Conx OK Home Conx Not
      ... When a client PC is physically removed from the domain it cannot access the ... Internet unless the VPN software is running. ... IPOCONFIG shows a local ip address (from a home router). ...
    • VPN drops frequently
      ... I have a VPN client connection to a Watchguard SOHO 6tc firewall router ...
    • Re: WRT54GL with DD-WRT VPN firmware - wheres the beef?
      ... the easiest way to deal with a VPN is to *FIRST* understand how ... as the NAT LAN connected to the terminating VPN server, to the client. ... Destination router: ... Gateway IP = ...
    • Re: WRT54GL with DD-WRT VPN firmware - wheres the beef?
      ... after the connection is established. ... the easiest way to deal with a VPN is to *FIRST* understand how ... as the NAT LAN connected to the terminating VPN server, to the client. ... Destination router: ...
    • Re: Nortel Contivity Client works without router but not with router.
      ... >> connected without the router, then it would say NAT Traversal disabled. ... >> The problem is that my client seems to be of the 'locked down' type, ... >> support routers when using VPN". ...