Hi,

I wish to try to configure a type of transparent tunnel.

Have three machines:
- PC A
- Linux X
- Linux Y

(See "Physical Topology" JPG)
PC A is connected to the network through "Linux X".
(Linux X, have two physical ports)

I wish to create packet flow like this: (See packet flow JPG)
1. PC A send packet (Through Linux X)
2. "Linux X" send this packet to "Linux Y" (over Tunnel ??)
3. "Linux Y" send this packet back to "Linux X" (Over Tunnel ??)
4. "Linux X" forward the packet to the network

(and same for back, PC B -> PC A)

The question is:
What is a recommended configuration?
I will be glad for any suggestion (GRE based, IP tables, etc.)

Thanks!

Attached Thumbnails

   

I'm sure you must have a very good reason to get up to all this jiggery pokery - get porn past watchful parents or something :-).

I would approach that using virtual interfaces. You configure something like 172.16.1.22.1 -- one nic on one tunnel
& 172.16.1.22.2 -- same nic but another tunnel. You make routes, and others are not 'in the loop.

I think linux tools support virtual interfaces, but switches don't necessarily do so.

Hi,

Thanks for the reply.

Ofcourse the interfaces on the left nic should be logical interfaces.

The main challenge is routing.
Because the same packet arrive from two different interfaces.
1. From PC A (1) and need to be forward up (2)
2. From Linux (3) and forward to PC B (4)

So, same packet (same source&destination IPs ) come from two different interfaces.
Is there a way to do one of the following:
1. routing based on the inbound interface?
2. if we assume using GRE interfaces. Can add GRE interface to bridge?


Thanks

I don't know GRE and have not used it. I('m not qualified to answer that.

When you speak of "tunneling" in this way, you are certainly speaking of some form of VPN = Virtual Private Networking.

You could be speaking of:

• ipSEC-based VPNs, the support for which is built deeply into the operating system, or ...
• OpenVPN, which runs as a privileged user-land process that uses low-level software interfaces ("tun" and "tap") provided by the OS.

The fundamental illusion provided by both is the same: that "it really is 'real.'"

Now, I presume that you already know how "physical" (IP ...) addressing works:

1. Each of the network interface cards (NICs) in your machine has an IP-address.
2. The "other" computers in your local network also have IP-addresses that are known to yours. (These computers, which can be reached directly, are said to belong to 'local subnets.') There are three ways to get there:
   1. They are directly connected.
   2. You go through a switch.
   3. You go through a (local...)router.
3. In order to get to "anywhere else" ... to anywhere that is not "on a subnet' ... the traffic must first be forwarded to a gateway, such as your Internet router.

So far, so good? Great.

VPNs extend this idea by defining additional subnets ... and the gateways which serve them ... entirely in software. The role of "router" (or "switch") is assumed by the VPN software, which transparently communicates to its peer using the system's (physical ...) network interfaces. Software clients cannot detect that these resources aren't "physically real."

Just like physically-attached subnets, these VPN-subnets either are (virtually ...) bridged, or they are connected by (virtual ...) routers. (VPNs provide software equivalents for both models.) If the subnets are routed, appropriate routing rules must be provided as-needed to route packets to the appropriate gateways correctly, exactly(!) as would be the case if the gateways were "real." VPN software generally provides for routing rules to be "set up" when a connection is made, then "torn down" when it is severed.)

2 members found this post helpful.

@sundialsvcs: Very simple and thorough summary!

Thanks for the detailed information.
I familiar with VPN and I will try it.

One of the challenges in my orig question is to redirect the same packet twice with tdiffrent result (one from PC and one back from the VPN).
I think that routing based VPN and IP tables could help me with this situation. I will give it a try.

Fundamental notion: OpenVPN (in tunnel mode) is a router.

And so, there are two levels to OpenVPN routing: let's call them "physical" and "logical." (My terminology.)

• Physical: The delivery of encrypted TCP/IP packets from one OpenVPN client/server to another. All of them must be able to communicate. These are real, physical resources: they are computers.
• Logical: Here I am referring to the IP-addresses that refer either to the various OpenVPN participants, or to any subnets that are connected to one another using OpenVPN. These addresses do not correspond to physical resources on the local subnet: instead, the local OpenVPN client/server acts as a gateway through which to reach them. The two cases are:
  1. Every OpenVPN server or client is allocated an IP-address, usually in the range 10.8.0.x, which refers specifically to them. This address-range is implemented by, and is reserved to, "OpenVPN itself."
  2. If any OpenVPN client or server exposes a subnet, the IP-addresses that are used within that subnet.

The physical picture is self-explanatory: real computers, sending encrypted UDP datagrams to one another, having IP-addresses that correspond to actual locations in their (possibly "world-wide") network.

All of the logical address-ranges must be routed, "as a gateway," back to the local OpenVPN client or server for delivery back to the other side. (To put it in TCP/IP terms, this is necessary because the local OpenVPN client or server is the "gateway router" that services those ["remote" ...] addresses.) As is always the case with TCP/IP, this chore must be done by anyone and everyone who might encounter them, or, as the case may be, through "static routes" helpfully provided by their local (hardware ...) router. One way or the other, every packet must be correctly routed.

IPTables rules are applied to addresses, regardless of how they are routed, but they must not conflict with that routing.