iptables drops packets after POSTROUTING

iptables nat virtualbox ubuntu-14.04 kernel-modules

5,628

The issue here appears to be with how VirtualBox emulates a network interface and/or the network stack. I was able to stand up another VBox Guest, configured as a dedicated gateway, using the same iptables rules, and was able to successfully redirect traffic to an arbitrary IP to my local InetSim instance.

5,628

Matt

Updated on September 18, 2022

Comments

Matt over 1 year

I have a malware analysis environment that will intercept traffic to arbitrary domains and Internet services using InetSim. I have a sandbox that has its DNS server set to the InetSim instance, and InetSim will answer any DNS query with its own IP address.

This setup works well for malware that calls back to a domain name, but if it attempts to connect directly with a hard coded IP address, my malware environment misses it. I'm attempting to use iptables to redirect any outbound traffic back to the InetSim instance on the same subnet, but packets appear to be getting dropped somewhere on the gateway machine.

There are three machines on the network

Gateway (Ubuntu 14.04LTS, running VirtualBox with host-only interface vboxnet0 at 192.168.54.1)
InetSim (VirtualBox VM, Remnux (Debian) Linux Distro, VBox host-only interface on eth0 at 192.168.54.2)
Sandbox (VirtualBox VM, WinXPSP2, VBox host-only interface at 192.168.54.102)

I am generally following the guide outlined in the netfilter NAT documentation, and my iptables rules look like this. Basically the rules are,

Outbound traffic (NOT intended for the 192.168.54.0/24 subnet) is sent to the gateway at 192.168.54.1
PREROUTING changes the destination address to the InetSim instance at 192.168.54.2
POSTROUTING changes the source address to the Gateway at 192.168.54.1

iptable rules

$ sudo iptables -v -t nat -L
Chain PREROUTING (policy ACCEPT 17465 packets, 1818K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   24  1763 LOG        all  --  vboxnet0 any     anywhere            !192.168.54.0/24      LOG level debug prefix "[PREROUTE OUTBOUND]"
   41  2824 DNAT       all  --  vboxnet0 any     anywhere            !192.168.54.0/24      to:192.168.54.2

Chain INPUT (policy ACCEPT 14623 packets, 1341K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 74 packets, 4809 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 73 packets, 4749 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   17   984 LOG        all  --  any    any     192.168.54.0/24      192.168.54.2         LOG level debug prefix "[POSTROUTE Inetsim]"
   41  2513 SNAT       all  --  any    any     192.168.54.0/24      192.168.54.2         to:192.168.54.1

As you can see from the packet counts, the rules are catching traffic. The weird thing is when I run tcpdump on both the gateway machine, and the InetSim machine, I see the rewritten packets from the gateway's capture, but no such packets from the InetSim machine's capture.

Gateway Capture

15:11:28.747298 ARP, Request who-has 192.168.54.1 tell 192.168.54.102, length 46
15:11:28.747305 ARP, Reply 192.168.54.1 is-at 0a:00:27:00:00:00, length 28
15:11:28.747471 IP 192.168.54.102.1041 > 2.3.4.5.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0
15:11:28.747513 IP 192.168.54.1.1041 > 192.168.54.2.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0

...SYN Repeated 2 more times...

15:11:33.748132 ARP, Request who-has 192.168.54.2 tell 192.168.54.1, length 28
15:11:33.748483 ARP, Reply 192.168.54.2 is-at 08:00:27:c7:4f:7c, length 28

InetSim Capture

10:11:28.649243 ARP, Request who-has 192.168.54.1 tell 192.168.54.102, length 46
10:11:28.649253 ARP, Reply 192.168.54.1 is-at 0a:00:27:00:00:00, length 46
10:11:28.649363 IP 192.168.54.102.1041 > 2.3.4.5.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0

...SYN Repeated 2 more times...

10:11:33.650248 ARP, Request who-has 192.168.54.2 tell 192.168.54.1, length 46
10:11:33.650266 ARP, Reply 192.168.54.2 is-at 08:00:27:c7:4f:7c, length 28

I've enabled trace and these are the entries in /var/log/syslog:

kernel: [22504.635493] TRACE: raw:PREROUTING:policy:2 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635504] TRACE: nat:PREROUTING:rule:1 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635508] [PREROUTE OUTBOUND]IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
kernel: [22504.635512] TRACE: nat:PREROUTING:rule:2 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635532] TRACE: filter:FORWARD:policy:1 IN=vboxnet0 OUT=vboxnet0 MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635536] TRACE: nat:POSTROUTING:rule:1 IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635538] [POSTROUTE Inetsim]IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
kernel: [22504.635541] TRACE: nat:POSTROUTING:rule:2 IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)

All other traffic and connections work as expected, but something is happening in the gateway. Yes, ip_forward is enabled. I know tcpdump sits in the middle of the routing process, and doesn't necessarily capture what's on the wire, so it seems like the packets are getting dropped somewhere between the PREROUTING and POSTROUTING tables. Any help would be greatly appreciated.

Matt over 9 years

The methodology you propose is spot on. Unfortunately, the problem was in the way VirtualBox emulates the interface and/or network stack, so no amount of flailing on iptables was helping.
GelosSnake over 6 years

Any idea how to workout the virtualbox emulation problem?