«

Hi all,

I would permit traffic incoming from a VPN towards another IPsec tunnel. It' quite vital the traffic between those 2
remote sites. So I thought to add use another interface where to terminate one of the tunnels. My doubts are about the
two interfaces will have 2 different IP address of the same subnet our provider supplied to us.

Do you think is there any kinf of implication of problem doing that?

Thanks,

Alex.

In article <7PRZd.16081$>, AM <> wrote:
:I would permit traffic incoming from a VPN towards another IPsec tunnel.

:So I thought to add use another interface where to terminate one of the tunnels.

Which platform is this for? 3/4 of your questions are about PIX, but
the other quarter are about your routers, so we cannot make any assumptions
about your needs when you do not say the devices involved.
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

Walter Roberson wrote:
> In article <7PRZd.16081$>, AM <> wrote:
> :I would permit traffic incoming from a VPN towards another IPsec tunnel.
>
> :So I thought to add use another interface where to terminate one of the tunnels.
>
> Which platform is this for? 3/4 of your questions are about PIX, but
> the other quarter are about your routers, so we cannot make any assumptions
> about your needs when you do not say the devices involved.

Sorry Walter ,
you are correct. The question is about PIX which has this limit.
We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
other IP (where we terminated all the VPN) belongs to.

Do you think there will be problems doing this?
Consider we want to "attach" to our network as an extension of our one and PC of that network ought to be able to go any
place we go, remote sites through VPNs as well.

Thanks,
Alex.

In article <MAVZd.15258$>, AM <> wrote:
:The question is about PIX which has this limit.
:We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
:so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
ther IP (where we terminated all the VPN) belongs to.

o you think there will be problems doing this?

In PIX 6, this cannot be done -- each [logical] interface must be in a different subnet.
PIX 7.0, for the 515/515E, 525, and 535 might remove this limit -- it introduces
major changes in the handling of interfaces. 7.0 will be available any day/week
now (but wasn't available for download as of late last week.)

[Note: I would hesitate to trust "highly important" data flows to the -first-
edition of any major rewrite of software!]


Perhaps due to the long hours I've been putting in lately, I have not grasped why
you are considering two interfaces. Could you expand on (or re-explain) that part?
--
"This was a Golden Age, a time of high adventure, rich living and
hard dying... but nobody thought so." -- Alfred Bester, TSMD

Walter Roberson wrote:
> In article <MAVZd.15258$>, AM <> wrote:
> :The question is about PIX which has this limit.
> :We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
> :so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
> ther IP (where we terminated all the VPN) belongs to.
>
> o you think there will be problems doing this?
>
> In PIX 6, this cannot be done -- each [logical] interface must be in a different subnet.
> PIX 7.0, for the 515/515E, 525, and 535 might remove this limit -- it introduces
> major changes in the handling of interfaces. 7.0 will be available any day/week
> now (but wasn't available for download as of late last week.)
>
> [Note: I would hesitate to trust "highly important" data flows to the -first-
> edition of any major rewrite of software!]
>
>
> Perhaps due to the long hours I've been putting in lately, I have not grasped why
> you are considering two interfaces. Could you expand on (or re-explain) that part?

As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
new one for the other half of company network. I would wait for the latest version of the Finesse
just to be sure there aren't bugs or announced caveauts.

Alex.

In article <qv1_d.664652$>, AM <> wrote:
:As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
:upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
:question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
:new one for the other half of company network.

Ah, do I understand correctly then that this is a hub/spoke issue?
That you want to relay between two VPN spokes using a single PIX
at the hub?

If so, and if you are not able to beg, borrow, or steal an IP in
a different public IP subnet, then you can work it like this:

____
{internet} ------> main outside IP-->|PIX|inside IP ----> switch ---> LAN
^ | | v
{internet} ----> another public IP-^ | |dmz IP <-------<
-----

The second tunnel is directed to one of the public IPs that is
static'd through to the outside interface (easier if it's the same
subnet as the main outside IP, but it doesn't have to be.) The PIX
is set to static that public IP to become the internal IP of the
DMZ interface. The packet is transfered in via the inside interface
to a switch, which forwards the packet back to the PIX, except to
a DMZ interface. The packet will be returning to the PIX by a
-different- interface than it exitted the PIX, so the PIX will accept
the packet rather than dropping it. The packet gets decapsulated
at the DMZ interface, and the interior packet gets routed --
finding that it is the outside interface that is the destination.
That's a different interface (outside) than the encapsulated packet
entered on (DMZ), so the transition is permitted, and the interior
packet will be duely encapsulated and transmitted to the other VPN
endpoint.

In the reverse direction, the packet from the first VPN hits the
outside interface, is decapsulated, the routing for the
interior packet destination points through the DMZ interface so
the packet heads out there, getting encapsulated as it goes.
{mumble here about mechanisms about getting the packet to head
from the DMZ interface back through the inside interface -- it's
easy if the device I show as a switch is a router instead; I would
need to think more about how to get the right routing if it really
is a switch.}
--
Are we *there* yet??

Walter Roberson wrote:
> In article <qv1_d.664652$>, AM <> wrote:
> :As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
> :upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
> :question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
> :new one for the other half of company network.
>
> Ah, do I understand correctly then that this is a hub/spoke issue?
> That you want to relay between two VPN spokes using a single PIX
> at the hub?
>
> If so, and if you are not able to beg, borrow, or steal an IP in
> a different public IP subnet, then you can work it like this:
>
> ____
> {internet} ------> main outside IP-->|PIX|inside IP ----> switch ---> LAN
> ^ | | v
> {internet} ----> another public IP-^ | |dmz IP <-------<
> -----
>
> The second tunnel is directed to one of the public IPs that is
> static'd through to the outside interface (easier if it's the same
> subnet as the main outside IP, but it doesn't have to be.) The PIX
> is set to static that public IP to become the internal IP of the
> DMZ interface. The packet is transfered in via the inside interface
> to a switch, which forwards the packet back to the PIX, except to
> a DMZ interface. The packet will be returning to the PIX by a
> -different- interface than it exitted the PIX, so the PIX will accept
> the packet rather than dropping it. The packet gets decapsulated
> at the DMZ interface, and the interior packet gets routed --
> finding that it is the outside interface that is the destination.
> That's a different interface (outside) than the encapsulated packet
> entered on (DMZ), so the transition is permitted, and the interior
> packet will be duely encapsulated and transmitted to the other VPN
> endpoint.
>
> In the reverse direction, the packet from the first VPN hits the
> outside interface, is decapsulated, the routing for the
> interior packet destination points through the DMZ interface so
> the packet heads out there, getting encapsulated as it goes.
> {mumble here about mechanisms about getting the packet to head
> from the DMZ interface back through the inside interface -- it's
> easy if the device I show as a switch is a router instead; I would
> need to think more about how to get the right routing if it really
> is a switch.}

I'm not sure to understand what you mean, but anyway this is the correct scenario.


------outside---- 1st provider --------------|-----|-----inside
| |
| |
--official VPN endpoint 4 our customers 1)--| |--- DMZ1
| |
| |--- DMZ2
-VPN coming from 2nd half of company net 2)--| |
-------

outside has an IP from 1 provider.
Don't care about outside and named DMZ interfaces.
Interface 1) and 2) will have 2 IP of the same IP range from a provider different from the outside one.

As PIX doesn't permit traffic coming from and going to the same interface, regarding only VPN, it is
expected to work fine, but my doubts were about using IP belonging to the same I pool but applied to
different interfaces. Perhaps my doubts should be cut off by the imperative "Are the traffic flowing
through different interface? - Y... es - OK Don't worry, it will work!".
I only want to be sure all aspects be considered without leaving off nothing.

Thanks,

Alex.