What is the simplest way to confirm or to disprove that Virtual Box virtual machines support GRE protocol

1

It is stated in VirtualBox manual (chapter 6) that VM network interfaces in "NAT" mode do not support GRE protocol. I'm currently trying to setup a pair of VMs as pptp server and client which would communicate via VM's network interfaces in "INTERNAL NETWORK" mode. I set up modern Linux OSes with pptp software on both machines and made some basic pptp configuration. However, I fail to connect the client to the server - server reports a failure when writing to GRE socket.

I now need a quick proof of principal ability to use the GRE protocol between VirtualBox VMs over a network in "INTERNAL" mode, such as a several-line .c program that would try to open/send/receive/close a GRE protocol connection, or like a specific lightweight tool to diagnose the GRE availability.

Any suggestions?

mbaitoff

Posted 2011-03-04T15:11:49.803

Reputation: 207

Are you able to communicate between the VMs in any other way? (ping, etc) – Majenko – 2011-03-04T15:17:08.763

Yes, I have a valid connection between VMs. 'Server' successfully gives the DHCP lease to the 'client', pings work. – mbaitoff – 2011-03-04T15:20:36.927

Answers

1

GRE and NAT in general don't get on well together. Usually you need some form of PPTP Passthrough technology on the NAT gateway for it to work. VirtualBox doesn't have that.

There is no reason at all why GRE shouldn't work on either bridged or internal network adaptors.

I just created 2 FreeBSD* VMs and linked them with an internal network called "intnet". I gave them both IP's on the 172.16.1.0/24 range.

I then created a GRE interface on each host and set the tunnelling to work between the two IP's I just allocated.

The GRE interfaces I put on the 172.16.2.0/24 range (.1 and .2)

I can ping happily between the two GRE interfaces.

(* I chose FreeBSD as it was what I had to hand and it's very easy to set up pure GRE tunnels for testing this kind of thing)

Majenko

Posted 2011-03-04T15:11:49.803

Reputation: 29 007

Yes, I would have to use "Bridged"-mode interface to emerge pptp traffic from VM's network, but this case is VM-to-VM. Before I commence the pptp client-server parameter debugging I must have a confirmation on GRE is working fine, since "GRE socket failure" report in daemon.log is suspicious. – mbaitoff – 2011-03-04T15:29:49.577

1I would suggest you look at such things as your linux firewall / packet filter, SELinux and PPTP configuration. Also check tcpdump to see if the packets on port 1723 are travelling around fine. – Majenko – 2011-03-04T15:35:52.367

Proof: http://twitpic.com/4613sz

– Majenko – 2011-03-04T15:40:46.060

What is the way to create GRE interfaces in BSD? In Linux it seems nothing but pptp/pptpd. – mbaitoff – 2011-03-04T16:13:19.227

ifconfig gre0 create – Majenko – 2011-03-04T16:14:30.990

Yes, you proved it in FreeBSD. So, my p-t-p connection issue binds either to Linux or to incorrect pptp/pptpd configuration. – mbaitoff – 2011-03-04T16:16:33.827

ifconfig gre0 create - nice. – mbaitoff – 2011-03-04T16:17:06.493

And that's why FreeBSD's superior to Linux ;) </flameinvite> – Majenko – 2011-03-04T18:13:07.617

Only if your 'ifconfig gre0 create' guessed automatically what peer addresses you meant to use. By the way, what was the netmask and route table of your VMs setup? Are you sure that ping was not using the internal network interfaces to reach the client instead of the p-t-p tunnel? – mbaitoff – 2011-03-04T18:34:24.150

Oh, I got the netmask. What was the routes? – mbaitoff – 2011-03-04T18:39:21.593

Create: ifconfig gre0 create // Set up tunnel between 172.16.1.1 and 172.16.1.2: ifconfig gre0 tunnel 172.16.1.1 172.16.1.2 // Set up IP addresses on tunnel - 172.16.2.1/24 communicating with 172.16.2.2: ifconfig gre0 inet 172.16.2.1/24 172.16.2.2 – Majenko – 2011-03-04T18:56:43.703

Asked: 2011-03-04T15:11:49.803

Viewed: 592 times

Active: 2014-10-17T10:32:33.600