VirtualBox port-forwarding

Today on my Munich-Florence train, I've waisted some time just trying some ways for "sshing" my puppet VirtualBox guest. Usually DHCPclient does everything and, once the ip address is got by the guest, I can easily "ssh" into it. This time, I had not a wifi connection and I've encoutered some annoying bounces on my ssh attempts. It looked like the guest was unreachable. I've instinctively tried every "nat", "bridged", "host-only" options.. and in the end .. it touched me to read the documentation :) (by the way, a very good paper) 

..and it was so i've discovered this official best practice to port-forward services on a VirtualBox guest

In this example (exactly extracted from the doc), we are going to portforwarding the SSH service, from our HOST 8888 port, to the GUEST (vm name: "Puppet Test Machine") on 22 port:

"sshService" is just a label.

In this way, our HOST will keep the forward on each interfaces. Anyway, it's possible to bind a specific interface though.

Now that we have our forward ready, we can connect the loopback on the given port
This rule will be permanet unless you explicitly remove it. See the rule properties:
Then delete the rule:

Mikrotik (winbox): VLAN and bridge

The other day i needed to add a new wifi access point in a new place in our building. Our network, like many others, is partitioned in VLANs. We have almost a dedicated VLAN for any different network segment.

Our best practice, where permitted, is to keep access points as untouched as possible, working the VLANs on the management switches. This develop a better/centralized net control to us. However this time the location was linked to the rest of the infrastructure by a non-management switch.



The "Port 40" is just where the trunk from the unlucky zone, ends on the management switch.

So, since the NON-management switch could not collaborate with us, we are forced to tag the VLAN traffic on the AP itself.



In this article we will start from the default Mikrotik configuration up to achieve our new Bridge for the new VLAN. The only stuff we have already configured, is the switch port (in our case the number 40) marked as tagged with VID 6. Im obviously referring to the management switch.

note: I assume you already have a server for this VLAN (dhcp server and so on ..)

otherwise: http://www.cyberciti.biz/tips/howto-configure-linux-virtual-local-area-network-vlan.html

Let's start opening winbox which allow us to connect the mikrotik through the proper mac address, avoiding lost of connection playing around bridge, VLANs ..

~$ wine winbox.exe

Create the new VLAN interface which will be tied to the master-local port on the router



Why master-local port?

The master-local port on the routerboard is the collection of the slave ports, then i act on that to give the same address (vid 6) for both wireless and every wire connections

Once the VLAN interface is created, move to the "Bridge" tab and close the existing one (bridge-local), by clicking "disable" (the red "X")



.. i've forgot .. this VLAN is basically for guests, so the new bridge will be named "bridge-guest". Open "Bridge" tab and add that:



Move in the near tab "Ports". Double click on "master-local" and replace the "interface" field with the VLAN interface "guest" and the "bridge" field with the just bridge-guest



Configure "wlan1" interface replacing the field "bridge" from ''bridge_local'' to ''bridge_guest''; then go to "IP/DHCP Client". If everything goes ok, you will be able to get an ip address from your server on the other side. When on the tab, click on "+" and in the "Interface" field, choose "bridge-guest". Click ok and



thats all.

D-link switches and .. "martians packets" ??

Device: Dlink DGS-1224T
Firmware: 4.21.01
IP addr: 10.2.2.8

I have a VLAN interface on my linux router built on eth2 with VID 6

eth2 = 10.2.2
eth2.6 = 10.6.6 (VLAN)

This VLAN is configured on my Dlink switch as well with untagged VLAN ports. My Dlink management interface is set on 10.2.2

Since we use shorewall as iptables interface, we have found this on syslog:

Sep 10 10:03:56 lurch kernel: [2651431.667008] martian source 10.2.2.1 from 10.2.2.8, on dev eth2.6
Sep 10 10:03:56 lurch kernel: [2651431.667011] ll header: ff:ff:ff:ff:ff:ff:00:15:63:45:05:c5:08:04

Martians ??

A possible explanation:
Packets with 10.2.2 as source reach the Dlink management interface on 10.2.2.8 (for management or just a nagios ping); as reply, the Dlink perform an ARP request like "Who has 10.2.2.x" on every ports, even on the VLAN 10.6.6 ones. As result, the Linux kernel see those 10.2.2 source packets on its eth2.6 interface and complains consequently.

A possible fixaround:
Force Dlink management interface being reachable from one network only, in my case 10.2.2, on "Configuration/802.1Q Management VLAN" tab.

Dnsmasq and the network "pushing" on CentOS

This simple post shows you how tu push networks to your clients using the Dnsmasq DHCP server.

A possible scenario would be, your DHCP server (192.168.0.1) gives you 192.168.0.x address but you also need to reach 172.16.x.x and 10.0.x x networks, for access to (for instance) some VPN resources in your LAN. Those networks are NOT handled by your DHCP server. The quick solution is to make your DHCP server "pushing" that networks. And that is possibile thanks to "121" dhcp-option.

Let's assume our network id may be "vicinet" (you can also miss the network id, of course):

dhcp-option = vicinet, 121, 10.0.0.0/16, 192.16.0.1, 172.16.0.0/16, 192.168.0.1

The format will always be:

dhcp-option = 'id_net', 121, NETWORK, GATEWAY

Shorewall and Pptp VPN on Ubuntu

~# apt-get install shorewall linux-pptp

PPP
Let's create a ppp peer file:

~# vim /etc/ppp/peers/zmo

I ve successfully tried these options

# Zmo PPTP VPN configuration
remotename zmo
linkname zmo
ipparam zmo
pty "pptp 149.79.X.X --nolaunchpppd" (remote VPN endpoint)
name username
require-mppe-128
refuse-eap
noauth
lock
noauth
refuse-pap
refuse-eap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate
persist
mtu 1400
mru 1400

Compile the chap-secret file

# Secrets for authentication using CHAP
# client server secret IP addresses
username zmo 2023n5t-w0re *

Network Interface
Fill the /etc/network/interfaces file. You can use the "unit x" parameter. This blessy option allows you to enumerate your ppp device (like ppp0, ppp1, ppp5 ..).

# Zmo Pptp VPN
auto ppp5
iface ppp5 inet ppp
provider zmo
unit 5

Try to get up the link, just giving

~# ifup ppp5

I raccomand to use this file (/etc/network/interfaces) even in the case you wanna add some route/net rules to your VPN device. Use the "post-up" options here.

# Zmo Pptp VPN
auto ppp5
iface ppp5 inet ppp
provider zmo
unit 5
post-up /sbin/route add 149.88.X.X gw 149.19.X.X
post-up /sbin/route add -net 150.84.X.X netmask 255.255.255.0 gw 150.84.X.X

Shorewall
Define a zone for the vpn on shorewall. I will define "zmo"

~# vim /etc/shorewall/interfaces

It should be looks like:

# For information about entries in this file, type "man shorewall-interfaces"
###############################################################################
#ZONE INTERFACE BROADCAST OPTIONS
wan eth0 detect tcpflags,nosmurfs,routefilter,logmartians,dhcp
dmz eth1 detect tcpflags,nosmurfs,routefilter,logmartians,dhcp
lan eth2 detect tcpflags,nosmurfs,routefilter,logmartians,dhcp
# VPN pptp
zmo ppp5 detect tcpflags,nosmurfs,routefilter,logmartians

Allow the vpn to be reached just by the lan

~# vim /etc/shorewall/policy

...
# Zmo Pptp VPN
lan zmo ACCEPT
all zmo REJECT
...

Masquerade the VPN traffic from that interface:

~# vim /etc/shorewall/masq

# For information about entries in this file, type "man shorewall-masq"
##############################################################################
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK
ppp5 - -

NOTE: an IP wont be needed here; shorewall will be masquerade the traffic with the interface IP address. Then we just can put a "-" in SOURCE/ADDRESS fields. The IP address would be needed if you would masquerade the traffic with a different IP address.

In the end, compile the "tunnels" shorewall file. You can retrieve a tunnels template file from the doc

~# cp /usr/share/doc/shorewall/default-config/tunnels /etc/shorewall

It should be looks like:

###############################################################################
#TYPE ZONE GATEWAY GATEWAY
# ZONE
pptpclient zmo 0.0.0.0/0