# Need to share connection from one NIC to another - bridge



## unknownuser (Apr 14, 2014)

Hello peps, this is going to be my first post here and I want to take this as opportunity to express my congrats with the FreeBSD team for maintaining this great resource.

Now back to my question. I have FreeBSD running as guest on VirtualBox and it is connected to the internet through a bridged interface with the host.

** What I want to achieve ** The FreeBSD box is connected to the internet through the em0 interface on the subnet 192.168.1.0/24, and I need to share the internet connection with the Ethernet card which is em1 and on a different subnet, I'd go with 192.168.2.0/24.

** Scenario **

{ Internet       >      host >       em0 }             >          { em1        >      *we need internet* }

Essentially FreeBSD is sharing both the Wireless and Ethernet NIC's with the host via virtual bridged, and the host is connected to the internet through the wireless.

I have spent two days on this, and the only way I got this to work is with natd(). However I was told (and I sort of knew it) that this is not the right way to do it, and that I should simply need to set up a bridge and bridge the subnets between em0() and em1(), and was suggested to follow the bridge section from the handbook, specifically the chapter 30.6.1 http://www.freebsd.org/doc/handbook/network-bridging.html.

** Gap **

However though I can't seem to be able get it to work. When I set up the bridge between em0 and em1 with no firewall whatsoever, the FreeBSD box is no longer able to access the internet.

If I assign to the bridge0 an IP on a subnet other than 192.168.1.0/24 it will not do anything beside setting the bridge on that subnet. The interesting part is if I run `dhclient bridge0`, it will associate an IP under the 192.168.1.0/24 (which is the subnet where the host is connected to) and I will get permission denied when pinging any IP's either from within the local network or a public IP.


```
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
	ether 08:00:27:a2:09:94
	inet6 fe80::a00:27ff:fea2:994%em0 prefixlen 64 scopeid 0x1
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
	ether 08:00:27:e3:41:fa
	inet6 fe80::a00:27ff:fee3:41fa%em1 prefixlen 64 scopeid 0x2
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
	inet 127.0.0.1 netmask 0xff000000
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 02:e1:41:20:a5:00
	inet 192.168.1.208 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=9<PERFORMNUD,IFDISABLED>
	id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
	maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
	root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
	member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
	        ifmaxaddr 0 port 2 priority 128 path cost 20000
	member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
	        ifmaxaddr 0 port 1 priority 128 path cost 20000
```


```
default            192.168.1.1        UGS         0        9 bridge
127.0.0.1          link#3             UH          0        0    lo0
192.168.1.0/24     link#4             U           0       16 bridge
192.168.1.208      link#4             UHS         0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               link#3                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%em0/64                     link#1                        U           em0
fe80::a00:27ff:fea2:994%em0       link#1                        UHS         lo0
fe80::%em1/64                     link#2                        U           em1
fe80::a00:27ff:fee3:41fa%em1      link#2                        UHS         lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0
ff01::%em0/32                     fe80::a00:27ff:fea2:994%em0   U           em0
ff01::%em1/32                     fe80::a00:27ff:fee3:41fa%em1  U           em1
ff01::%lo0/32                     ::1                           U           lo0
ff02::/16                         ::1                           UGRS        lo0
ff02::%em0/32                     fe80::a00:27ff:fea2:994%em0   U           em0
ff02::%em1/32                     fe80::a00:27ff:fee3:41fa%em1  U           em1
ff02::%lo0/32                     ::1                           U           lo0
```


```
hostname="vboxbsd"
keymap="it.iso.kbd"
sshd_enable="YES"
ntpd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
vboxguest_enable=YES
vboxservice_enable=YES
hald_enable="YES"
dbus_enable="YES"
rpcbind_enable="YES"

# enable inetd server
inetd_enable="YES"

# Enable as LAN gateway
gateway_enable="YES"


# dhcpd
dhcpd_enable="YES"				# dhcpd enabled?
dhcpd_flags="-q"				# command option(s)
dhcpd_conf="/usr/local/etc/dhcpd.conf"	# configuration file
dhcpd_ifaces="bridge0"				# ethernet interface(s)
#dhcpd_withumask="022"			# file creation mask

cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm em1 up"
ifconfig_em0="up"
ifconfig_em1="up"
```

As you can see I have left em0 and em1 not configured in rc.conf, just as mentioned on the handbook: *"If the bridge host needs an IP address, set it on the bridge interface, not on the member interfaces. The address can be set statically or via DHCP."*.

I would appreciate any effort to strain this out once and for good..

Thanks in advantage and I do apologise for the long post.


----------



## junovitch@ (Apr 14, 2014)

*Re: Need to share connection from one NIC to another - bridg*

Do clients on 192.168.1.0/24 need to talk seamlessly inward to 192.168.2.0/24 without mucking with port forwarding?  If they don't, then NAT would be perfectly acceptable.  That wasn't clear based off what you posted.

If the 192.168.1.0/24 subnet does need to talk to 192.168.2.0/24 directly, I'm wondering if the virtual MAC address the bridge assigns is causing the permissions error and inability to connect to the Internet. Technically as far as Virtualbox is concerned, that MAC of the bridge0 interface isn't owned by that VM so I would think you are bound to see weird issues.  I'm purely speculating though and would need to know exactly what error you are seeing to make a better call.  If that doesn't bother Virtualbox, I would think you would need to do something along these lines in addition to what you already have added to your /etc/rc.conf.   Something like this.

```
ifconfig_bridge0="inet 192.168.1.2/24"
ifconfig_bridge0_alias0="inet 192.168.2.1/24" 
default_router="192.168.1.1"
```
- On 192.168.1.1 router, setup static route for 192.168.2.0/24 destined to 192.168.1.2 address on the bridge interface of the FreeBSD VM.

You can also accomplish this with basic routing, no NAT, and no bridge interface.
- On 192.168.1.1 router, setup static route for 192.168.2.0/24 to the address of em0 interface (192.168.1.2 shown below) on the FreeBSD VM.
- On the FreeBSD VM

```
ifconfig_em0="inet 192.168.1.2/24"
ifconfig_em1="inet 192.168.2.1/24" 
default_router="192.168.1.1"
```


----------



## unknownuser (Apr 15, 2014)

*Re: Need to share connection from one NIC to another - bridg*

Hey, thank you for the kind reply and I do apologise for my late response but I had lots to do during these days.

Okay as you suggested I tried to set up a static route from the Linux router to the FreeBSD em0. Unfortunately the result is that I still get permission denied when pinging anything from the FreeBSD VM, and from the Linux router I am unable to ping either 192.168.1.2 and 192.168.2.2.

Here's how I have set the static route on the router


```
sudo ip route add 192.168.2.0/24 via 192.168.1.2 dev br-lan
```

The routing table output on the router


```
0.0.0.0         151.6.156.72    0.0.0.0         UG        0 0          0 pppoe-wan
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
151.6.156.72    0.0.0.0         255.255.255.255 UH        0 0          0 pppoe-wan
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-lan
192.168.2.0     192.168.1.2     255.255.255.0   UG        0 0          0 br-lan
```

On the FreeBSD side instead 

Routing table


```
Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGS         0        3    em0
127.0.0.1          link#3             UH          0        0    lo0
192.168.1.0/24     link#1             U           0       64    em0
192.168.1.2        link#1             UHS         0        0    lo0
192.168.2.0/24     link#2             U           0        0    em1
192.168.2.1        link#2             UHS         0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               link#3                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%em0/64                     link#1                        U           em0
fe80::a00:27ff:fea2:994%em0       link#1                        UHS         lo0
fe80::%em1/64                     link#2                        U           em1
fe80::a00:27ff:fee3:41fa%em1      link#2                        UHS         lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0
ff01::%em0/32                     fe80::a00:27ff:fea2:994%em0   U           em0
ff01::%em1/32                     fe80::a00:27ff:fee3:41fa%em1  U           em1
ff01::%lo0/32                     ::1                           U           lo0
ff02::/16                         ::1                           UGRS        lo0
ff02::%em0/32                     fe80::a00:27ff:fea2:994%em0   U           em0
ff02::%em1/32                     fe80::a00:27ff:fee3:41fa%em1  U           em1
ff02::%lo0/32                     ::1                           U           lo0
```

I have also collected some tcpdump logs, which I believe do not show anything interesting.


```
19:42:34.777827 IP (tos 0x0, ttl 55, id 26141, offset 0, flags [none], proto TCP (6), length 137)
    74.125.232.131.https > 192.168.1.110.59957: Flags [P.], cksum 0x0984 (correct), seq 1092654721:1092654806, ack 4074013527, win 661, options [nop,nop,TS val 2959933233 ecr 371699984], length 85
19:42:34.778218 IP (tos 0x0, ttl 64, id 13245, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.59957 > 74.125.232.131.https: Flags [.], cksum 0x7674 (correct), ack 85, win 8186, options [nop,nop,TS val 371714909 ecr 2959933233], length 0
19:42:37.778463 IP (tos 0x0, ttl 64, id 53487, offset 0, flags [DF], proto TCP (6), length 681)
    192.168.1.110.60308 > 75.101.145.87.http: Flags [P.], cksum 0xfdb5 (correct), seq 1370729717:1370730346, ack 3447693242, win 8192, options [nop,nop,TS val 371717907 ecr 2357578775], length 629
19:42:37.918876 IP (tos 0x0, ttl 42, id 10940, offset 0, flags [DF], proto TCP (6), length 52)
    75.101.145.87.http > 192.168.1.110.60308: Flags [.], cksum 0x15c2 (correct), ack 629, win 34, options [nop,nop,TS val 2357579272 ecr 371717907], length 0
19:42:38.466850 IP (tos 0x0, ttl 42, id 10941, offset 0, flags [DF], proto TCP (6), length 405)
    75.101.145.87.http > 192.168.1.110.60308: Flags [P.], cksum 0x9c40 (correct), seq 1:354, ack 629, win 34, options [nop,nop,TS val 2357579325 ecr 371717907], length 353
19:42:38.466878 IP (tos 0x0, ttl 64, id 11564, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60308 > 75.101.145.87.http: Flags [.], cksum 0xf1b6 (correct), ack 354, win 8169, options [nop,nop,TS val 371718593 ecr 2357579325], length 0
19:42:38.780489 IP (tos 0x0, ttl 64, id 38249, offset 0, flags [DF], proto TCP (6), length 910)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [P.], cksum 0xbc36 (correct), seq 2655443412:2655444270, ack 2213678315, win 8192, options [nop,nop,TS val 371718904 ecr 2583123391], length 858
19:42:38.780502 IP (tos 0x0, ttl 64, id 37878, offset 0, flags [DF], proto TCP (6), length 93)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [P.], cksum 0x3ce5 (correct), seq 858:899, ack 1, win 8192, options [nop,nop,TS val 371718904 ecr 2583123391], length 41
19:42:38.949322 IP (tos 0x30, ttl 50, id 23985, offset 0, flags [DF], proto TCP (6), length 52)
    199.16.156.52.https > 192.168.1.110.60311: Flags [.], cksum 0xf254 (correct), ack 899, win 82, options [nop,nop,TS val 2583149012 ecr 371718904], length 0
19:42:38.949334 IP (tos 0x30, ttl 50, id 23986, offset 0, flags [DF], proto TCP (6), length 93)
    199.16.156.52.https > 192.168.1.110.60311: Flags [P.], cksum 0x950e (correct), seq 1:42, ack 899, win 82, options [nop,nop,TS val 2583149012 ecr 371718904], length 41
19:42:38.949343 IP (tos 0x0, ttl 64, id 61132, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [.], cksum 0xd1d8 (correct), ack 42, win 8189, options [nop,nop,TS val 371719072 ecr 2583149012], length 0
19:42:38.953639 IP (tos 0x30, ttl 50, id 23987, offset 0, flags [DF], proto TCP (6), length 143)
    199.16.156.52.https > 192.168.1.110.60311: Flags [P.], cksum 0xf461 (correct), seq 42:133, ack 899, win 82, options [nop,nop,TS val 2583149015 ecr 371718904], length 91
19:42:38.953652 IP (tos 0x0, ttl 64, id 37075, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [.], cksum 0xd179 (correct), ack 133, win 8186, options [nop,nop,TS val 371719076 ecr 2583149015], length 0
19:42:38.953664 IP (tos 0x30, ttl 50, id 23988, offset 0, flags [DF], proto TCP (6), length 294)
    199.16.156.52.https > 192.168.1.110.60311: Flags [P.], cksum 0x8d35 (correct), seq 133:375, ack 899, win 82, options [nop,nop,TS val 2583149015 ecr 371718904], length 242
19:42:38.954037 IP (tos 0x0, ttl 64, id 1665, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [.], cksum 0xd091 (correct), ack 375, win 8176, options [nop,nop,TS val 371719076 ecr 2583149015], length 0
19:42:38.955443 IP (tos 0x30, ttl 50, id 23989, offset 0, flags [DF], proto TCP (6), length 89)
    199.16.156.52.https > 192.168.1.110.60311: Flags [P.], cksum 0x412e (correct), seq 375:412, ack 899, win 82, options [nop,nop,TS val 2583149015 ecr 371718904], length 37
19:42:38.955458 IP (tos 0x0, ttl 64, id 22503, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60311 > 199.16.156.52.https: Flags [.], cksum 0xd05e (correct), ack 412, win 8189, options [nop,nop,TS val 371719077 ecr 2583149015], length 0
19:42:42.781106 IP (tos 0x0, ttl 64, id 3741, offset 0, flags [DF], proto TCP (6), length 681)
    192.168.1.110.60308 > 75.101.145.87.http: Flags [P.], cksum 0xe43d (correct), seq 629:1258, ack 354, win 8192, options [nop,nop,TS val 371722895 ecr 2357579325], length 629
19:42:42.919824 IP (tos 0x0, ttl 42, id 10942, offset 0, flags [DF], proto TCP (6), length 52)
    75.101.145.87.http > 192.168.1.110.60308: Flags [.], cksum 0xfc78 (correct), ack 1258, win 36, options [nop,nop,TS val 2357579773 ecr 371722895], length 0
19:42:43.384376 IP (tos 0x0, ttl 42, id 10943, offset 0, flags [DF], proto TCP (6), length 405)
    75.101.145.87.http > 192.168.1.110.60308: Flags [P.], cksum 0x8907 (correct), seq 354:707, ack 1258, win 36, options [nop,nop,TS val 2357579809 ecr 371722895], length 353
19:42:43.384389 IP (tos 0x0, ttl 64, id 46386, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.110.60308 > 75.101.145.87.http: Flags [.], cksum 0xd8d5 (correct), ack 707, win 8169, options [nop,nop,TS val 371723496 ecr 2357579809], length 0
```

Now asking to your question above, 192.168.2.0/24 do not specifically need to communicate with 192.168.1.0/24 in this scenario, however it would be a plus one if they could talk to eachother. Actually I can have them talking to eachother with natd. 

Lastly, this could well be the result of my sucky routing knowledge in term of configuration, even though I am not sure what I am doing wrong.

Thanks


----------



## junovitch@ (Apr 15, 2014)

*Re: Need to share connection from one NIC to another - bridg*

Can you tell me the exact error message for the "permission denied" you are seeing?

On to the routing.  The Linux command looks right for the route and the entry in the routing table is good.  The FreeBSD side is good.  I see you dropped the bridge interface, that's good and will keep things simple.  The default route points out and the other two subnets are directly connected and don't need routes.  When it comes to your routing knowledge, just remember for simple stuff like this to just point a default route "out" in the direction of the Internet.  Then point static routes "in" where-ever you have little stub networks like the 192.168.2.0/24 in this example.  It's just practice and a bit of mental visualization to get the hang of mapping it all out in your head.

Can you provide context on the tcpdump?  That looks to be on your Linux router and doesn't tell me anything except there was some web browsing going on.  It would be much more helpful to run something like `tcpdump -n -i em0 host 192.168.1.1` on your FreeBSD VM during the time you are pinging it from the Linux router's 192.168.1.1 gateway address.  That way we can actually see if packets are being received/sent.  An `arp -an` (both on the Linux router and FreeBSD VM) could also prove useful to check layer 2 can see each other.

If the subnets talking to each other is ideal, then we can work towards that premise.  You already have gateway_enable="YES" and don't have a firewall enabled so it should be fairly straight forward.


----------



## unknownuser (Apr 17, 2014)

*Re: Need to share connection from one NIC to another - bridg*

Thank you for you help and for the very detailed informations..

Anyways here's all the informations you have asked me to provide.

`arp -an` on the linux router


```
? (192.168.1.199) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.139) at <incomplete> on br-lan
? (192.168.1.205) at <incomplete> on br-lan
? (192.168.1.190) at <incomplete> on br-lan
? (192.168.1.105) at <incomplete> on br-lan
? (192.168.1.100) at 00:0e:08:12:6c:5a [ether] on br-lan
? (192.168.1.110) at 68:a8:6d:34:db:f4 [ether] on br-lan   (this is the host where FreeBSD in running as a guest)
? (192.168.1.10) at 02:e1:41:20:a5:00 [ether] on br-lan
? (192.168.1.186) at <incomplete> on br-lan
? (192.168.1.96) at <incomplete> on br-lan
? (192.168.2.1) at 02:e1:41:20:a5:00 [ether] on br-lan
? (192.168.1.1) at 02:e1:41:20:a5:00 [ether] on br-lan
? (192.168.1.222) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.167) at cc:fa:00:f0:31:35 [ether] on br-lan
? (192.168.1.132) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.142) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.2) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.238) at <incomplete> on br-lan
? (192.168.1.208) at 02:e1:41:20:a5:00 [ether] on br-lan
? (192.168.1.233) at 68:a8:6d:34:db:f4 [ether] on br-lan
? (192.168.1.118) at 00:19:7e:1c:aa:66 [ether] on br-lan
```

`arp -an` on FreeBSD VM


```
? (192.168.2.1) at 08:00:27:e3:41:fa on em1 permanent [ethernet]
? (192.168.1.1) at 64:70:02:cc:23:a9 on em0 expires in 1171 seconds [ethernet]
? (192.168.1.2) at 08:00:27:a2:09:94 on em0 permanent [ethernet]
```

The output of tcpdump from the FreeBSD VM when pining it from the linux router

```
20:22:52.044961 IP 192.168.1.110.55205 > 192.168.1.1.22: Flags [P.], seq 1728:1776, ack 1297, win 8192, options [nop,nop,TS val 422321405 ecr 71495497], length 48
20:22:52.045817 IP 192.168.1.1.22 > 192.168.1.110.55205: Flags [.], ack 1776, win 2896, options [nop,nop,TS val 71495513 ecr 422321405], length 0
20:22:52.269539 IP 192.168.1.110.55205 > 192.168.1.1.22: Flags [P.], seq 1776:1824, ack 1297, win 8192, options [nop,nop,TS val 422321628 ecr 71495513], length 48
20:22:52.274245 IP 192.168.1.1.22 > 192.168.1.110.55205: Flags [.], ack 1824, win 2896, options [nop,nop,TS val 71495536 ecr 422321628], length 0
20:22:52.281820 IP 192.168.1.1.22 > 192.168.1.110.55205: Flags [P.], seq 1297:1345, ack 1824, win 2896, options [nop,nop,TS val 71495537 ecr 422321628], length 48
20:22:52.281834 IP 192.168.1.110.55205 > 192.168.1.1.22: Flags [.], ack 1345, win 8189, options [nop,nop,TS val 422321638 ecr 71495537], length 0
20:22:52.292338 IP 192.168.1.1.22 > 192.168.1.110.55205: Flags [P.], seq 1345:1441, ack 1824, win 2896, options [nop,nop,TS val 71495538 ecr 422321638], length 96
20:22:52.292351 IP 192.168.1.110.55205 > 192.168.1.1.22: Flags [.], ack 1441, win 8186, options [nop,nop,TS val 422321648 ecr 71495538], length 0
20:22:52.293587 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 0, length 64
20:22:53.329250 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 1, length 64
20:22:54.352357 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 2, length 64
20:22:55.292770 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 3, length 64
20:22:56.293344 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 4, length 64
20:22:57.264042 IP 192.168.1.110.36339 > 192.168.1.1.53: 1106+ A? syndication.twitter.com. (41)
20:22:57.292088 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 5, length 64
20:22:57.298746 ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 46
20:22:57.318109 IP 192.168.1.1.53 > 192.168.1.110.36339: 1106 2/0/0 A 199.16.156.201, A 199.59.150.46 (73)
20:22:58.445981 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 6, length 64
20:22:58.446001 ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 46
20:22:59.291916 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 7, length 64
20:22:59.297766 ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 46
20:23:00.291722 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 8, length 64
20:23:01.309689 ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 46
20:23:01.309689 ARP, Reply 192.168.1.2 is-at 08:00:27:a2:09:94, length 28
20:23:01.311449 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 9, length 64
20:23:02.334897 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 10, length 64
20:23:03.359591 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 11, length 64
20:23:04.382020 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 12, length 64
20:23:05.290562 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 13, length 64
20:23:06.428859 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 14, length 64
20:23:07.453479 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 15, length 64
20:23:08.476378 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 16, length 64
20:23:09.500159 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 17, length 64
20:23:10.289357 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 18, length 64
20:23:11.289126 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 19, length 64
20:23:12.365929 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 20, length 64
20:23:13.389418 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 21, length 64
20:23:14.412942 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 22, length 64
20:23:15.287700 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 23, length 64
20:23:16.459143 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 24, length 64
20:23:17.483503 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 25, length 64
20:23:18.301874 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 26, length 64
20:23:19.325690 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 27, length 64
20:23:20.286694 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 28, length 64
20:23:20.417405 ARP, Request who-has 192.168.1.110 tell 192.168.1.1, length 46
20:23:20.417431 ARP, Reply 192.168.1.110 is-at 68:a8:6d:34:db:f4, length 46
20:23:21.372663 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 29, length 64
20:23:22.287161 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12136, seq 30, length 64
```

Picture of the permission denied output (did not have a shell access to collect the log as normally)







Also, even though I have set defaultrouter="192.168.1.1" in /etc/rc.conf, anytime I reboot the system with NATD disable it will ignore the default router option set in  /etc/rc.conf and I will need to enter it manually. And is when I do add it manually that it will start giving me permission denied when pinging something, otherwise it will just go with no route to host.

Additionally, something even more weird that I am coming across is that when I am done with the subnet linking configuration and I have collected all the logs needed by you, I would set the system back to NATD and I would restart the network stack as well as I would start NATD expecting that everything would normally work, instead it will keep on throwing  permission denied till I do restart the system. Flushing the routing table and adding the gw manually doesn't help either..

At this point I am stating to think this might be an issue specifically related to Virtuabox itself since I have easily done this in the past and I have never runt in this kind of issues.

Thanks for the help


----------



## junovitch@ (Apr 22, 2014)

*Re: Need to share connection from one NIC to another - bridg*

That's interesting.  I've never seen the permission denied errors that you are seeing.  How do you have your network configured with Virtualbox?  Is Adapter 1 just a bridged adapter to wlan0 and Adapter 2 something else?


----------



## SirDice (Apr 22, 2014)

*Re: Need to share connection from one NIC to another - bridg*



			
				unknownuser said:
			
		

> The output of tcpdump from the FreeBSD VM when pining it from the linux router
> 
> ```
> 20:22:52.044961 IP 192.168.1.110.55205 > 192.168.1.1.22: Flags [P.], seq 1728:1776, ack 1297, win 8192, options [nop,nop,TS val 422321405 ecr 71495497], length 48
> ...


Small tip, use something like `tcpdump -ni em0 not port 22` if you do this remotely. Adding the not port 22 will filter out your own admin (SSH) connection. Tcpdump prints text which is sent over SSH, those packets are picked up by tcpdump(8), which prints text over SSH, etc. Creating more or less a loop that generates more and more traffic clouding the data you actually want to look at.


----------

