Either method will work. I personally prefer GRE, but there should be no practical difference between the two for your use case. (GRE can transport other layer3 protocols than just IP, though.)
The only thing to really keep in mind is that GRE incurs a tiny bit of extra overhead as opposed to IPinIP.
Yes, from the packet switching point-of-view, VXLAN is just a matter of sticking some encapsulation on top of an L2 frame: something that other protocols do as well.
The real difference it makes is at the control and management layer.
VXLAN evolved as a Data Center technology, so the ability to span a WAN is just an additional advantage, not the thing that ...
Preventing outbound ssh connections, and thus any tunnels, would require a complete blockade of outbound connections via deep packet inspection. Looking at ports will be 100% useless. You have to look at the actual packet payload to know it's SSH. (this is what websense is doing.)
The only other option is setting up a "proxy" host. Lock down the ...
It is also worth considering how tunneling impacts the path MTU. It would be ideal for the infrastructure between tunnel endpoints to support a larger MTU. This will avoid issues with fragmentation and broken pmtud.
Tunnel interfaces have many uses, including participating in a larger VPN configuration. A VPN setup usually has many parts, including encryption, authentication, routing, and finally, the tunneling. Tunneling is also used for IPv4/IPv6 coexistence setups, such as encapsulating IPv6 packets in IPv4 headers, creating GRE tunnels, and multicast tunneling. The ...
I would HIGHLY recommend getting rid of HSRP and using routing over the tunnels (both up all the time), whether OSPF or EIGRP. Set an inferior metric on one of the tunnels at both ends. Problem solved.
HSRP is BAD NEWS over WAN. I am struggling to see what use the HSRP is. As you're now seeing it also causes a lot of issues when overlaid on top of routing.
There is another method, if you're merely looking at stopping people from using SSH as a proxy workaround why not rate limit it to say 20kB/sec or so, that ends up painful enough for web, but imperceptible for console use.
If you wanted to allow file transfers at normal speed this wouldn't be an option though.
Running a tunnel over GRE has the added benefit of being pretty much protocol-agnostic, so you can of course use it for IPv6 later on.
With that said however, there's equally nothing stopping you running 6in4 or ip6ip6 alongside ipip, so the question really comes down to whether there's any tangible gain for you by choosing GRE and using it for ...
As you've already stated, VXLAN is L2 tunneling over IP. It's a solution to use any L3 network for creating a L2 segment.
While this is also possible with other protcols, VXLAN doesn't require additional infrastructure or special transport (given IP is available) and it can also use a single tunnel for up to 16 million subtunnels - with a large ...
The tunnel is a point-to-point interface, all packets sent over the tunnel are received and processed by the remote device. When the remote device realizes the packet is destined for a subnet-local address it sends it back across the tunnel to your Microtik. You are hitting a the ping-pong vulnerability in IPv6.
If you control the SSH server and the firewall then you can control access by blocking access to whatever port the SSH server is using (22 by default). Unless the port has previously been opened, then inbound connections are likely to be blocked anyway, although you'll probably found that outbound connections will be allowed. With the right design and ...
I've also read that it's possible to make it appear as a flat network i.e. everything on the same LAN. This is the piece i am missing, can someone help me to understand how this is possible?
Some tunneling technologies provide Ethernet over IP services. For instance, research about these topics:
Ethernet over GRE
Originally, WANs were mostly defined by specific layer 1/2 protocols (Frame Relay, HDLC, SONET, etc) that they used, but Ethernet has taken over, and the others are rapidly fading into history. The term "WAN" now generally describes a network that covers some larger geographical area than a LAN. Sounds vague? It is.
Some WANs, like the Internet are public,...
Your tunnel source and destination addresses are wrong. They should be 22.214.171.124 and 126.96.36.199 on RA and the opposite on RB.
There are many different ways to explain this, but essentially, the route to the tunnel endpoint cannot be through the tunnel. In your case, in order to send a packet (from RA) to 192.168.1.2, RA has to encapsulate it ...
Some vendors support IEEE 802.1ae/MACsec for encryption layer two between the access switch and its endpoints. I'm afraid I can't be any more help as I have no experience with it (and frankly it sounds like a nightmare to administer).
Cisco IOS/NX-OS/etc. software does not configure the bandwidth for a virtual tunnel interface based on the physical interface to which it is assigned; instead, it applies a default "bandwidth" statement to the interface that depends on model of hardware and the version of software it is running (on many devices the default "BW" for a tunnel is 8kbps!).
The DNS is issued by default from your local host, not from the proxy, when using SOCKS (probably because SOCKS4 didn't support other way).
Make sure you have checked the checkbox "Remote DNS" in the Proxy configuration of the Firefox:
The consensus of the comments is
The segments are inside IPv4
The protocol of TCP happens to be 6 and it's not its IP version number
As you say, if you're looking for 4s vs 6s for protocol versions, you will find them!
So what's the difference between GRE+IPsec and IPsec only?
In GRE+IPsec the original IP packet is encapsulated in a GRE tunnel packet. The GRE packet is then encapsulated in the IPSec packet.
The most common reason for doing this is to allow broadcast and multicast across the tunnel. Neither is supported by IPSec alone. GRE can also encapsulate non-IP ...
Encapsulation is the normal method of using a lower layer mechanism for moving your data. E.g. HTTP is encapsulated by TCP, TCP is encapsulated by IPv4, IPv4 is encapsulated by an Ethernet frame.
Encapsulating backwards or at the same layer - IP in GRE, IP in IPsec, IP in UDP, Ethernet in L2TP, ... is called tunneling. It somewhat ties a knot in your ...
GRE is just a tunneling protocol - its main reason for existence is toplogy hiding/bypass.
Some examples include:
Tunneling MPLS across a network that may otherwise not support it - MPLS shims are not IP-based, therefore wrapping them in a GRE tunnel allows two routers to appear adjacent when there could be a number of intermediate IP-only devices.
You are confusing me with the "default gateway" thing. The source address is the address on the device from which you are pinging, not the gateway for that subnet.
Suppose I have two addresses, 10.11.12.13 and 172.16.17.18 on my computer. I want to ping on the respective interfaces (logical or physical). I ping from the source (-S) with each of the ...
Yes it is possible, and Everton gave you some features that help you do that, but...
...please don't do it !
I know a single LAN over two (or more) distant sites seems nice for machine migration (it can keep the same IP) or auto-discovering protocols, but by bridging two remote LAN you create a single failure domain.
By bridging remote LAN, you will ...
Tunneling involves encapsulating the packets to be tunneled inside an outer packet. The tunneled packets are the payload of the encapsulating packets.
You will be creating a new IPv4 packet header to encapsulate the IPv6 packets, just as if the IPv6 packets were TCP segments. The new IPv4 packet headers don't really care what is in the payload, other than ...
IKE is (in massively simplified terms/practically explained) just a way of establishing an IPSec VPN tunnel, and IPSec VPN tunnels don't inherently support multicast.
You can put a GRE tunnel inside of an IPSec VPN tunnel which will support multicast, and other non-IP Layer 3 protocols, like apple talk, IPX, and NHRP, which explains why DMVPN which uses ...
I've read that IPv6 over IPv4 tunnels are a security risk because IPv6 traffic cannot be intercepted by Intrusion Detection Systems and Firewalls.
That's completely untrue. Maybe some specific, very old IDS systems and firewalls are unable to detect this, but modern equipment sure can.
However, if a network has native IPv6 support it shouldn't be subject ...
Off the top of my head, the most common would be:
IPSEC (Internet Protocol SECurity)
SSL (Secure Sockets Layer)
PPTP (Point-to-Point Tunnelling Protocol)
L2TPv3 (Layer 2 Tunnelling Protocol)
As for which layers they are each working at, it really comes down to what you mean by "working".
L2TPv3, PPTP and IPSEC all establish and operate over the top of IP ...
Tunnels change the network topology. They let routers A and B be logically adjacent even if they don’t have a physical connection. They also let you run one type of network over another type of network.
Run IPv6 network over IPv4-only infrastructure.
Connect “internal security zone” networks over “external” routers.
Logically connect slave ...
There's definitely not a single way to provide end-to-end encryption as you've asked, but packet sniffing as you wish to protect against can really only performed at few places in a typical corporate environment. 1 - physical network taps between devices 2 - span/monitor ports on devices 3 - attacks that force traffic to go where it is not intended.
For #1 -...