Hi,
My Shorewall router has a physical "LAN" interface with several VLANs
(lan.1, lan.13, lan.14, lan.15, etc.) and a physical "SOC" interface
with just one VLAN (interface name 'soc' and vlan name 'soc.50').
The SOC interface is connected to a specific port on my main/root
switch which is configured as "tagged VLAN ID 50". There are only a
few other ports in this switch that have the same Tagged VLAN ID 50
where there are a few VMware ESXi hosts. These physical hosts run,
among others, a virtual machine with one of its virtual interfaces in
VLAN ID 50. This interface is supposed to receive all the network
traffic I send it via port mirroring (it's a network traffic
analyzer).
I do not have system access to the SOC virtual machine, but it's
network interface is configured like this:
eth2 Link encap:Thernet HWaddr 00:50:56:92:76:E5
inet addr:192.168.245.2 Bcast:192.168.245.7 Mask:255.255.255.248
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Now, if I wanted to make sure that there are no VLAN configuration
errors in the root switch then would the following two nmap commands
prove that the eth2 interface of the SOC VM is reachable through the
soc.50 interface on my Shorewall router, hence demonstrating that hey
are all in the right VLAN?
# nmap -e soc.50 192.168.245.2
Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-10 10:08 CET
Nmap scan report for 192.168.245.2
Host is up (0.00030s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3306/tcp open mysql
5432/tcp open postgresql
5666/tcp open nrpe
9999/tcp open abyss
MAC Address: 00:50:56:92:76:E5 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 13.30 seconds
# nmap -e soc 192.168.245.2
Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-10 10:09 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.59 seconds
If the above is OK I now need to find out why the SOC VM admin is
reporting that its eth2 interface is not receivng any tcp traffic at
all. An example one-minute dump would look something like this:
# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:10:32.442888 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:10:33.824278 ARP, Request who-has 10.215.144.61 tell 10.215.144.62, length 46
11:10:40.850874 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:10:48.603916 IP 10.215.147.148.netbios-dgm >
10.215.255.255.netbios-dgm: NBT UDP PACKET(138)
11:10:48.603959 IP 10.215.147.148.netbios-dgm >
10.215.255.255.netbios-dgm: NBT UDP PACKET(138)
11:10:50.727001 00:14:22:b1:f0:40 (oui Unknown) > Broadcast, ethertype
Unknown (0x88a2), length 60:
0x0000: 1000 ffff ff01 0000 0000 0000 0000 0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
11:10:54.946143 ARP, Request who-has 10.215.145.80 tell
192.168.215.96, length 46
11:10:56.566752 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
11:10:57.569831 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
11:10:58.583229 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
11:11:01.017122 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:11:01.881836 ARP, Request who-has 10.215.144.31 tell 10.215.144.21, length 46
11:11:05.817536 ARP, Request who-has 10.215.144.62 tell
192.168.215.96, length 46
11:11:06.154704 ARP, Request who-has 10.215.144.31 tell
10.215.147.148, length 46
11:11:08.043224 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:13:72:47:1b:dc (oui Unknown), length 300
11:11:11.666233 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:11:22.943389 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:11:34.674216 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
11:11:35.676505 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
11:11:35.763314 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300
11:11:35.947354 ARP, Request who-has 10.215.144.62 tell
192.168.215.96, length 46
11:11:36.689890 ARP, Request who-has 10.215.246.101 tell
192.168.215.128, length 46
^C
22 packets captured
22 packets received by filter
0 packets dropped by kernel
This doesn't match the much bigger amount of traffic I see if I
tcpdump -n -i soc.50 on the shorewall firewall. So for some reason the
traffic is not properly port mirrored.
Here's how I set up port mirroring on the Shorerwall router
(IF_SOC_VLAN=soc.50):
# cat /etc/shorewall/started
if [ "$COMMAND" = start -o "$COMMAND" = restart -o "$COMMAND" = reload ]; then
if [ ! -z "${IF_SOC_VLAN}" ] && [ "x${FW_TYPE}" = "xfirewall" ]; then
for lan_vid in 13 14 15
do
run_tc qdisc add dev ${IF_LAN}.${lan_vid} ingress
run_tc filter add dev ${IF_LAN}.${lan_vid} parent ffff:
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
run_tc qdisc add dev ${IF_LAN}.${lan_vid} handle 1: root prio
run_tc filter add dev ${IF_LAN}.${lan_vid} parent 1:
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
done
fi
fi
Here's a Shorewall dump which shows that traffic from lan.13, lan.14
and lan.15 should be mirrored to soc.50:
https://drive.google.com/file/d/1nMv_CEbY69zmQtto6PCuPb7xC_yG8FZd/view?usp=sharing
eg. the SOC VM's eth2 interface should be receiving what I see on the
soc.50 interface:
10:42:30.028234 IP 10.215.144.16 > 10.215.144.33: ICMP echo request,
id 1024, seq 3604, length 24
10:42:30.028562 IP 10.215.144.33 > 10.215.144.16: ICMP echo reply, id
1024, seq 3604, length 24
This ping request/reply is just an example of traffic seen in VLAN ID
13 which should be sent to soc.50, hence eth2 on the SOC VM.
What could be wrong here?
Could it be that the mirrored traffic is actually blocked by the root
switch even if my nmap tests were successful in finding the SOC VM?
Do you see anything wrong in my Shorewall port-mirroring configuration?
Regards,
Vieri
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
