|
|
Have routing issue im trying to get my head around.
My network is setup like this:
-------------------------------------------------------------------------------------------------------
REMOTE NODE
(public ip)
|
|
NET
|
|
(public IP)
FIREWALL
(private ip range 192.168.50.0 /24)
|
|
SWITCH
|
|
(192.168.50.100)
SERVER (listening service)
-------------------------------------------------------------------------------------------------------
I have nodes sending data to my listening service using the PUBLIC IP as the
nodes target destination address, NAT to listening service, all works fine.
I need to install an IPSEC vpn conneciton to allow additional nodes to
connect to my listening service over VPN. These nodes will use the target
destination IP 192.168.50.100 instead of a public IP. The routing at the
remote node end should be ok as managed by my ISP.
-------------------------------------------------------------------------------------------------------
REMOTE NODE
|
|
NET
|
|
(public IP)
FIREWALL
(private ip range 192.168.50.0 /24)
|
|
SWITCH _ _ _ _ _ _ (192.168.50.99) VPN TERMINATION HARDWARE (10.10.10.10) _
_ _ _ _ _ _ _ _ _ _ _ (10.10.10.99) remote node
|
|
(192.168.50.100)
SERVER (listening service)
-------------------------------------------------------------------------------------------------------
1. My options are to install 3rd party VPN termation hardware as shown above
and make it form part of my 192.168.50.0 /24 private lan. If i do this how
can 192.168.50.100 route to 10.10.10.99 ? what do i need to configure to
ping 10.10.10.99 for example ?
2. I can probably get my FIREWALL to create the IPSEC conneciton to
(10.10.10.99) remote node. Again how can 192.168.50.100 route to 10.10.10.99
under this circumstance ? ... what would i need to configure to ping
10.10.10.99 for example ?
I understand you cannot NAT over IPSEC.
Thank you for any advice.
|
|
Routing is not handled by the ISP. The ISP, or anything on the outside of
the Tunnel only see the "outside" of the Tunnel,...nothing sees the inside
of the Tunnel. It doesn't matter if it is PPTP, L2TP, or IPSec Tunneling.
Look at the routing situation. Routing has 3 componenets,...Source
Interface (IP#),...the Gateway (aka first-hop router),...and the
Destination.
Site-to-Site VPN and Remote Access VPN act totally different.....
With Remote Access VPN:
Source = the IP granted via DHCP [usually] that the Client received
when establishing the VPN connection.
Router = Same thing as the Source. Remote Access VPN works just
like a Dialup connection and the Client becomes their own Gateway for
anything that isn't on their own local subnet. This means that anything not
destined for the local subnet is passed to the "Dialup Adapter" **no matter
what it is**.
Destination = Just obvoiusly the Destiantion. Since it is not on
the Clients own local subnet the traffic is just "dropped" on the Dialup
Connection [aka the VPN] and it gets to where it is going.
With Site-to-Site VPN:
Site-to-Site VPN is completely different and works more like a Private
Leased Line. This means the VPN Router behaves just like a regular LAN
Router between two LAN or WAN segments,...that is a key point, so remember
that. The tunneling protocol (PPTP, L2TP, or IPSec Tunneling) is irrelevant
to the routing.
Source = The Client's own normal IP# on the LAN it lives on
Router = The routing device that creates the VPN Tunnel.
Destination = Just obvoiusly the Destiantion.
The LAN's Routing Scheme has to independently on its own know how to route
the traffic. Just because the Site-to-Site VPN link "exists" does not mean
it will get used. In a *multi-subnet* LAN there is already a LAN Router
handling the LAN's routing decisions,...so you just add a "route" to the LAN
Router that tells it to use the VPN Router as the "gateway" for the subnet
on the opposite side of the VPN. In some cases you may want to configure
your firewall device's LAT to include the remote subnet so that it doesn't
try to pass the traffic to the raw Internet and may need to add the same
"route" to the Firewall that you did the LAN Router.
But if you have a *single-subnet* LAN then there is no LAN Router, which is
bad,...and things can get ugly. Remember what I told you to remember up
above? Why?,...because your VPN Router just suddenly became the "official"
LAN Router for the LAN but unfortunately all the Clients are using the
Firewall as the Default Gateway instead of the VPN Router [now your LAN
Router]. To compound that the VPN Router is most likely using an Internet
located device as its Default Gateway and not your own Firewall, and if you
change that Default Gateway without "setting the stage" first you will take
down the Tunnel.
To compound it even more the Firewall [if it is a good one] will not handle
acting as a "router" by just giving it a Static Route to the VPN router for
the remote subnet because the traffic will appear spoofed. This happens
because the packets don't follow the same path in both directions,..so the
Firewall does not see both sides of the conversation which "breaks the
statefullness" and the traffic is then decared to be "spoofed" traffic.
This is called the "Network behind a Network Scenario".
Well, if we are only talking about one or two Client machines you can just
configure them with Static Routes to use the VPN Router for the remote
subnet. But if we are talking about the whole LAN that just isn't smart to
do. To satisfy the whole LAN you would have to:
1. Create a Static Route on the VPN Router that tells it to use its
favorite Internet device as the gateway to contact the Public IP of the VPN
Router on the other end. This will "set the stage" to be able to change its
Default Gateway to be the local Firewall while still being able to create
the Tunnel. Once the Tunnel is re-established again it should then know
what to do with the Private traffic already.
2. Create a Static Route on the Firewall that tells it to use the VPN
Router as the gateway to the Private Subnet on the other end of the VPN.
Then add the Private IP Range from the other subnet to the Firewall's LAT so
it doesn't confuse it for Internet traffic.
3. Configure all the Clients on the LAN to use the VPN Device as the
Default Gateway instead of the Firewall
From this point you will treat the VPN Router as the LAN Router and the
subnets on each side of the Tunnel will behave just like two subnets in the
same building together with a regular LAN router between them.
Now just when you think you have been punished enough,...you will have to
repeat all this on the opposite side of the Tunnel within the other LAN.
After all, it takes two sides, properly configured, to have a TCP/IP
converstation.
"Scott" <nospam123[ at ]yahoo.co.uk> wrote in message
news:ebKfZ25XJHA.1528[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > Have routing issue im trying to get my head around.
>
> My network is setup like this:
>
>
> -------------------------------------------------------------------------------------------------------
> REMOTE NODE
> (public ip)
> |
> |
> NET
> |
> |
> (public IP)
> FIREWALL
> (private ip range 192.168.50.0 /24)
> |
> |
> SWITCH
> |
> |
> (192.168.50.100)
> SERVER (listening service)
> -------------------------------------------------------------------------------------------------------
>
>
> I have nodes sending data to my listening service using the PUBLIC IP as
> the nodes target destination address, NAT to listening service, all works
> fine.
>
> I need to install an IPSEC vpn conneciton to allow additional nodes to
> connect to my listening service over VPN. These nodes will use the target
> destination IP 192.168.50.100 instead of a public IP. The routing at the
> remote node end should be ok as managed by my ISP.
>
>
>
> -------------------------------------------------------------------------------------------------------
>
> REMOTE NODE
> |
> |
> NET
> |
> |
> (public IP)
> FIREWALL
> (private ip range 192.168.50.0 /24)
> |
> |
> SWITCH _ _ _ _ _ _ (192.168.50.99) VPN TERMINATION HARDWARE (10.10.10.10)
> _ _ _ _ _ _ _ _ _ _ _ _ (10.10.10.99) remote node
> |
> |
> (192.168.50.100)
> SERVER (listening service)
> -------------------------------------------------------------------------------------------------------
>
>
>
>
> 1. My options are to install 3rd party VPN termation hardware as shown
> above and make it form part of my 192.168.50.0 /24 private lan. If i do
> this how can 192.168.50.100 route to 10.10.10.99 ? what do i need to
> configure to ping 10.10.10.99 for example ?
>
>
> 2. I can probably get my FIREWALL to create the IPSEC conneciton to
> (10.10.10.99) remote node. Again how can 192.168.50.100 route to
> 10.10.10.99 under this circumstance ? ... what would i need to configure
> to ping 10.10.10.99 for example ?
>
>
> I understand you cannot NAT over IPSEC.
>
>
> Thank you for any advice.
>
|
|
I based my other post on the VPN Router being a Separate "duel-homed" Device
sitting on the network edge independently of the exisiting firewall. But if
you use the existing Firewall to create the VPN then most things will take
care of themselves. The Firewall will just have two jobs,...a Firewall and
a LAN Router at the same time.
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
|
|
thanks for the reply Phillp. Will take a bit of time to run over and digest
that. Your second post does make sence , using existing firewall to
terminate. My ISP has to worry about routing because they are supplying me
with a private IP range and my private IP range for some of my subnets clash
with their subnets .... they also have other customers doing the same thing.
Once again thanks you very much for taking the time to post.
Scott
|
|
"Scott" <nospam123[ at ]yahoo.co.uk> wrote in message
news:OdAAb4eYJHA.1188[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > terminate. My ISP has to worry about routing because they are supplying me
> with a private IP range and my private IP range for some of my subnets
> clash with their subnets .... they also have other customers doing the
> same thing.
Why in the world would you involve yourself in something like that!? This
means that anything that you ever,... or will ever,... want to make
available to the "outside" will be totally at the mercy of the ISP's skills,
abilities, lack of desire, or silly security fantasies for it to work or
fail.
Do you realise that it would be impossible to an VPN device on the "real"
Internet to "target" your VPN Device because you run unreachable addresses.
The ISP will have to setup a "VPN Pass-through" setup (which isn't about
routing) in order for the Tunnel to terminate at your location. Do you also
realise the the ISP is effectively your Firewall?...the ISP has to
Reverse-NAT or Reverse-proxy anything that you ever expect to do *inbound*.
It is kind of like your LAN is sleeping in bed one night and then wakes up,
rolls over, and finds that the ISP is sleeping in the same bed with it.
You need to get out of that situation as fast as you can.
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
|
|
Hi Phillip
Thanks again for the reply.
[Quoted Text] > Do you realise that it would be impossible to an VPN device on the "real"
> Internet to "target" your VPN Device because you run unreachable
> addresses.
I understand. Its not important for any real internet nodes to route to my
target. Only important for my end point to route to the remote nodes over
the tunnel and vice versa.
> The ISP will have to setup a "VPN Pass-through" setup (which isn't about
> routing) in order for the Tunnel to terminate at your location. Do you
> also
realise the the ISP is effectively your Firewall?
Thats is a very good point. I must be able to manage this however using a
firewall on my VPN endpoint hardware. Once the VPN tunnel is established I
only need a couple of ports to passthrough my firewall from the ISP network
to my network. Not sure if this makes sence however , when the VPN tunnel is
created can i still firewall incoming traffic or does it all hit my LAN ?
Note: my local destination lan is isolated into its own vlan but i would
still like to filter the traffic hitting it.
> ...the ISP has to Reverse-NAT or Reverse-proxy anything that you ever
> expect to do *inbound*.
I dont fully understand this, are you saying the ISP has to Reverse-NAT or
Reverse-proxy any traffic from my nodes on the ISP network to my network ?
not exactly sure what this means.
Thank again for your time
Best regards
|
|
"Scott" <nospam123[ at ]yahoo.co.uk> wrote in message
news:OVLTlDDZJHA.684[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] >> ...the ISP has to Reverse-NAT or Reverse-proxy anything that you ever
>> expect to do *inbound*.
>
> I dont fully understand this, are you saying the ISP has to Reverse-NAT or
> Reverse-proxy any traffic from my nodes on the ISP network to my network ?
> not exactly sure what this means.
No, I mean from the Public Internet to your LAN.
Picture your LAN as being just another subnet "behind" another subnet within
the same building. You are in charge of your LAN but someone else is in
charge of the other one and they are the one with the Firewall and the
Public Internet on the outside of their firewall. You can't do anything
outside your own subnet that the other guy on the other subnet doesn't do
for you.
Then you put a VPN capable Firewall between the subnets, which means it is
effectively in the "middle" of the overall LAN and you want to create a
site-to-site tunnel somewhere. You are totally at the mercy of the other
guy on the other subnet. This is a very bad situation to be in.
In this illustration you are you and the other guy is the ISP and your LAN
is "effectively" just simply nothing more than a subnet "inside" the ISP's
LAN. To me that is horrible. But anyway, the point is that the ISP is the
only one who can help you and if they don't have the smarts to just
*automatically & already know* what to do without you having to ask people
in public news groups then you are just really really screwed and should get
out of that situation. Because in the end, in this situation, they are
really the ones who run your LAN,...not you.
I don't think I can do anything more with this beyond what little I have
already suggested in the earlier posts.
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Technet Library
ISA2004
http://technet.microsoft.com/en-us/library/cc302436(TechNet.10).aspx
ISA2006
http://technet.microsoft.com/en-us/library/bb898433(TechNet.10).aspx
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html
Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc
Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx
Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesecurity/partners/hardwarepartners.mspx
-----------------------------------------------------
|
|
|