Re: [FW1] NAT across a VPN - brain teaser challenge - read carefully

[Bob Brandt <bbbrandt@FW1-NOSPAMmmm.com>]

Dan,

Actually there is a way to get the local machine to send the traffic to the local
router.   There is a feature called the "arp hack" which can
be turned on on most routers whereby they will respond to the arp requests of
addresses which they have not seen active on the local lan.
It is called "proxy arp" on a cisco.  It was originally developed to make lan
systems work better with workstations which did not
understand subnet masks.

So as long as the 10.10.10.x address used on the remote LAN are not exactly the same
ones used locally, you can turn on proxy arp
and make the routing work.   Once the traffic gets to the router you can NAT
(perhaps even use host routes without NAT) and send
it to the other side.   Proxy arp will not work however if you have the exact same
address being used on both sides.

Bob Brandt, 3M, bbbrandt@3m.com


Dan Hitchcock wrote:

> Hey everyone -
>
> Somebody tell me if I'm off my nut here, but if you have two LANs with the
> same address scheme (i.e. machines on both ends with the same address),
> there is NO WAY to get connectivity without STATIC NATs.  This has to do
> with IP routing, not firewalls or encryption.
>
> My reasoning:
> If my machine is 10.10.10.120, and I'm on the 10.10.10.0/24 network, any
> request sent to 10.10.10.* will generate an ARP request on the local
> network, and succeed or fail on that local segment.  You can put all the
> rules you want on your default gateway (be it a router or firewall), but
> they won't do a bit of good, since the client will never send any requests
> to the default gateway - why would it?  It's just making a local LAN
> request.  There is no way I know of to "tag" an IP packet such that it heads
> for the default gateway even though the client knows the destination to be
> on its local network (according to the address and mask), except to put
> static routes on that machine, and corresponding static return routes on the
> remote machine.  This is an administrative nightmare far worse than
> re-ip'ing a network.
>
> An alternative would be to ARP the remote addresses to the firewall and use
> static routes there, but if this is the case, you still can't have any
> duplicate addresses between the two networks, so you probably have to re-ip
> anyway, so why not re-ip to an addressing scheme that doesn't overlap?
>
> If anyone out there has a resolution to this dilemma, I would be very very
> interested to hear it.
>
> Dan Hitchcock
> CCNA, MCSE
> Network Engineer
> Xylo, Inc. (formerly employeesavings.com)
>> The work/life solution for corporate thought leaders
>
> -----Original Message-----
> From: Murphy, Paul [mailto:Paul.Murphy@lloydstsb.co.uk]
> Sent: Thursday, October 05, 2000 9:25 AM
> To: fw-1-mailinglist@lists.us.checkpoint.com
> Subject: RE: [FW1] NAT across a VPN
>
>
> Seeing as the encapsulation happens last on the outbound, and first on the
> inbound, can't we just translate one of the lans behind a static pool?
>
> I guess that is the question being asked.
>
> I can't see any reason why it shouldn't work.
>
> Paul.
>
>
> -----Original Message-----
> From: postmaster@us.britannica.com [mailto:postmaster@us.britannica.com]
> Sent: 05 October 2000 15:07
> To: fw-1-mailinglist@lists.us.checkpoint.com
> Subject: [FW1] NAT across a VPN
>
> I read Frank's post and while I am testing this in our lab I wanted to see
> if anyone had come up with a solution already.
>
> Problem:
> local-net 10.10.10.0
> partner-net 10.10.10.0
> IKE VPN
>
> Is it possible to NAT either you or your partner -net, BEFORE or after it
> crosses the VPN ?
>
> Objective:
> To allow a VPN between two companies without re-addressing either company.
>
> Jon
>
> Date: Wed, 4 Oct 2000 22:38:56 -0500
> From: Frank Knobbe <FKnobbe@KnobbeITS.com>
> Subject: RE: [FW1] VPN + NAT
>
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For these types of VPN's you probably want to add two Translation
> rules that disable NAT for connections through the VPN tunnel. The
> two rules are:
>
> MyNet - PartnerNet - Any - Original - Original - Any
> PartnerNet - MyNet - Any - Original - Original - Any
>
> Make sure you set routes in your network that directs traffic aimed
> at the PartnerNet to your firewall.
>
> Regards,
> Frank
>
> ============================================================================
> ====
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> <http://www.checkpoint.com/services/mailing.html>
> ============================================================================
> ====
>
> ----------------------------------------------------------------------------
> -----
> This e-mail is intended only for the above addressee. It may contain
> privileged information. If you are not the addressee you must not copy,
> distribute, disclose or use any of the information in it. If you have
> received it in error please delete it and immediately notify the
> sender.
>
> evolvebank.com is a division of Lloyds TSB Bank plc.
> Lloyds TSB Bank plc, 71 Lombard Street, London EC3P 3BS.  Registered in
> England, number 2065.  Telephone No: 020 7626 1500
> Lloyds TSB Scotland plc, Henry Duncan House, 120 George Street,
> Edinburgh EH2 4LH. Registered in Scotland, number 95237.  Telephone
> No:>
> Lloyds TSB Bank plc and Lloyds TSB Scotland plc are regulated by the
> Personal Investment Authority and represent only the Scottish Widows
> and Lloyds TSB Marketing Group for life assurance, pensions and
> investment business.
>
> Members of the UK Banking Ombudsman Scheme and signatories to the UK
> Banking Code.
> ----------------------------------------------------------------------------
> ------
>
> ============================================================================
> ====
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ============================================================================
> ====
>
> ================================================================================
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ================================================================================



================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================