Re: Strong Host Model in OpenBSD network stack
On 2019-12-10, Bastian Kanbach wrote: > Good evening all, > > following up on the previous discussions, I noticed that the network > stack changed recently [1] (limited to cases when packet forwarding is > enabled). > > What's the idea behind it, as it seemed to be unlikely that this default > would be changed at all? It helps with https://www.openwall.com/lists/oss-security/2019/12/05/1 for simpler cases. For more complex cases where forwarding is also used, restrictions can be made with PF (urpf-failed; this was possible before, too).
Re: Strong Host Model in OpenBSD network stack
Good evening all,
following up on the previous discussions, I noticed that the network
stack changed recently [1] (limited to cases when packet forwarding is
enabled).
What's the idea behind it, as it seemed to be unlikely that this default
would be changed at all?
Thanks,
Bastian
[1] https://marc.info/?l=openbsd-tech&m=157580561114203
Am 18.10.19 um 08:56 schrieb Claudio Jeker:
> On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
>> Hello,
>>
>> recently I was performing some checks that relate to the "Strong Host
>> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
>> different than I expected. I always assumed that the network stack of
>> OpenBSD was following the "Strong Host Model", but I might be wrong with
>> that:
> OpenBSD does follow the "Weak Host Model". Has always been like that.
>
>> Basically the Strong Host Model means that the network stack "accepts
>> locally destined packets if the destination IP address in the packet
>> matches an IP address assigned to the network interface on which the
>> packet was received."
>>
>> FreeBSD and NetBSD have a sysctl property for this, called
>> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
>> However for OpenBSD I haven't seen such a property at all.
>>
>>
>> Basically my setup consisted of the following virtual machines and
>> network interfaces (IP-Forwarding disabled):
>>
>>
>> VM 1 (OpenBSD 6.5):
>>
>> em0: 192.168.100.1/24 ("Internal Network")
>>
>> em1: 10.0.0.97/24 ("NAT")
>>
>>
>> VM 2 (Ubuntu Server 18.10):
>>
>> ens33: 192.168.100.2/24 ("Internal Network")
>>
>>
>>
>>
>>
>> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
>> interfaces are associated with the same Virtualbox network, and both IP
>> addresses are part of the same /24 subnet.
>>
>> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
>> addresses are part of different subnets and no routes were configured.
>>
>>
>> Then I performed 2 tests:
>>
>>
>> Test 1:
>>
>> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
>> packet was NOT answered by VM1.
>>
> This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
> will not answer. The host model only matters for Layer 3.
>
>> Test 2:
>>
>> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
>> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
>> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
>> MAC address of interface em0).
>>
>>
>> While the behaviour of Test 1 indicates that the Strong Host Model is
>> followed, Test 2 shows the behaviour of a "Weak Host Model".
>
> No, Test 1 is not the right test for the host model.
>
>> What of both is actually supposed to be the default for OpenBSD? Is
>> there any kernel parameter to control these behaviours, like
>> net.inet.ip.check_interface for FreeBSD or NetBSD?
> We don't have a button and just follow the "Weak Host Model".
> You can enforce a strong model per interface with pf(4):
>
> block in on !em0 inet to (em0)
>
> or
>
> block in
> pass in on em0 to (em0)
> pass in on em1 to (em1)
>
Re: Strong Host Model in OpenBSD network stack
Hello all,
thank you very much for your insights. Indeed I did not intend to start
discussions whether the OpenBSD default makes sense or not.
Actually I'd agree that using the Weak Model is beneficial since it
wouldn't break routing functionality. My question was mainly about what
the default is, but this question was answered now.
@Theo: I agree, there's probably only a tiny subset of people actually
setting check_interfaces to 1.
During some further research I found that only Windows versions from
Vista and newer are following the Strong Model in a strict way. However
this makes sense, since I can't think of any Routers running Windows.
Again, thank you call.
Cheers,
Bastian
Am 18.10.19 um 08:56 schrieb Claudio Jeker:
> On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
>> Hello,
>>
>> recently I was performing some checks that relate to the "Strong Host
>> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
>> different than I expected. I always assumed that the network stack of
>> OpenBSD was following the "Strong Host Model", but I might be wrong with
>> that:
> OpenBSD does follow the "Weak Host Model". Has always been like that.
>
>> Basically the Strong Host Model means that the network stack "accepts
>> locally destined packets if the destination IP address in the packet
>> matches an IP address assigned to the network interface on which the
>> packet was received."
>>
>> FreeBSD and NetBSD have a sysctl property for this, called
>> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
>> However for OpenBSD I haven't seen such a property at all.
>>
>>
>> Basically my setup consisted of the following virtual machines and
>> network interfaces (IP-Forwarding disabled):
>>
>>
>> VM 1 (OpenBSD 6.5):
>>
>> em0: 192.168.100.1/24 ("Internal Network")
>>
>> em1: 10.0.0.97/24 ("NAT")
>>
>>
>> VM 2 (Ubuntu Server 18.10):
>>
>> ens33: 192.168.100.2/24 ("Internal Network")
>>
>>
>>
>>
>>
>> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
>> interfaces are associated with the same Virtualbox network, and both IP
>> addresses are part of the same /24 subnet.
>>
>> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
>> addresses are part of different subnets and no routes were configured.
>>
>>
>> Then I performed 2 tests:
>>
>>
>> Test 1:
>>
>> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
>> packet was NOT answered by VM1.
>>
> This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
> will not answer. The host model only matters for Layer 3.
>
>> Test 2:
>>
>> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
>> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
>> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
>> MAC address of interface em0).
>>
>>
>> While the behaviour of Test 1 indicates that the Strong Host Model is
>> followed, Test 2 shows the behaviour of a "Weak Host Model".
>
> No, Test 1 is not the right test for the host model.
>
>> What of both is actually supposed to be the default for OpenBSD? Is
>> there any kernel parameter to control these behaviours, like
>> net.inet.ip.check_interface for FreeBSD or NetBSD?
> We don't have a button and just follow the "Weak Host Model".
> You can enforce a strong model per interface with pf(4):
>
> block in on !em0 inet to (em0)
>
> or
>
> block in
> pass in on em0 to (em0)
> pass in on em1 to (em1)
>
Re: Strong Host Model in OpenBSD network stack
On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
> Hello,
>
> recently I was performing some checks that relate to the "Strong Host
> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
> different than I expected. I always assumed that the network stack of
> OpenBSD was following the "Strong Host Model", but I might be wrong with
> that:
OpenBSD does follow the "Weak Host Model". Has always been like that.
> Basically the Strong Host Model means that the network stack "accepts
> locally destined packets if the destination IP address in the packet
> matches an IP address assigned to the network interface on which the
> packet was received."
>
> FreeBSD and NetBSD have a sysctl property for this, called
> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
> However for OpenBSD I haven't seen such a property at all.
>
>
> Basically my setup consisted of the following virtual machines and
> network interfaces (IP-Forwarding disabled):
>
>
> VM 1 (OpenBSD 6.5):
>
> em0: 192.168.100.1/24 ("Internal Network")
>
> em1: 10.0.0.97/24 ("NAT")
>
>
> VM 2 (Ubuntu Server 18.10):
>
> ens33: 192.168.100.2/24 ("Internal Network")
>
>
>
>
>
> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
> interfaces are associated with the same Virtualbox network, and both IP
> addresses are part of the same /24 subnet.
>
> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
> addresses are part of different subnets and no routes were configured.
>
>
> Then I performed 2 tests:
>
>
> Test 1:
>
> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
> packet was NOT answered by VM1.
>
This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
will not answer. The host model only matters for Layer 3.
>
> Test 2:
>
> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
> MAC address of interface em0).
>
>
> While the behaviour of Test 1 indicates that the Strong Host Model is
> followed, Test 2 shows the behaviour of a "Weak Host Model".
No, Test 1 is not the right test for the host model.
> What of both is actually supposed to be the default for OpenBSD? Is
> there any kernel parameter to control these behaviours, like
> net.inet.ip.check_interface for FreeBSD or NetBSD?
We don't have a button and just follow the "Weak Host Model".
You can enforce a strong model per interface with pf(4):
block in on !em0 inet to (em0)
or
block in
pass in on em0 to (em0)
pass in on em1 to (em1)
--
:wq Claudio
Re: Strong Host Model in OpenBSD network stack
On Fri, Oct 18, 2019 at 07:21:42AM +0200, Remi Locherer wrote: > On Thu, Oct 17, 2019 at 10:33:41PM -0600, Theo de Raadt wrote: > > > Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > > > replies immediately. > > > > > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > > > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > > > interface was contacted. > > > > How many users set those variables? > > > > A global seems this is a misguided place to establish such a policy. > > > > If it was good and neccessary for everyone on all interfaces and had no > > downsides, they would have turned it on. But they didn't. > > > > A similar feature "urpf-failed" which is more nuanced is available in > > pf.conf, and you can properly use it on a per-interface basis, also > > selecting to do so based un other per-rule options, rather than having > > a 'global rule'. > > > > Something blocked FreeBSD or NetBSD from turning this into the default. > > What was that reason -- was it too damaging? > > > > (I'm going to assume the people with so-called 'strong' views didn't win > > the battle, and the so-called 'weak' view pervailed, probably because > > the 'strong' option created breakage and prevents the dominant > > operational model of Getting-Shit-Done. That's why I ask how many > > people in real life subscribe the 'strong' view by turning on this > > option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, > > everyone is so busy getting on about their lives they don't flip any > > knobs which don't provide an immediately confirmable and neccessary > > value). > > > > from source port source os source to dest port dest > > This rule applies only to packets with the specified source and > > destination addresses and ports. > > > > Addresses can be specified in CIDR notation (matching > > netblocks), > > as symbolic host names, interface names or interface group > > names, > > or as any of the following keywords: > > > > any Any address. > > no-route Any address which is not currently routable. > > route label Any address matching the given route(8) label. > > self Expands to all addresses assigned to all > > interfaces. > >Any address matching the given table. > > urpf-failed Any source address that fails a unicast reverse > > path > > forwarding (URPF) check, i.e. packets coming in on > > an interface other than that which holds the route > > back to the packet's source address. > > > > Convince us we should change to the strong model, and I'll embrace it. > > > > You won't convince us to make a global which people don't understand... > > > > This "strong" model is a bad fit for routers. > > When this model is needed we have pf (antispoof or urpf-failed). > Alternatively rdomains can be used (put a network interface with management > services on it in a separate rdomain). > The BSD systems and IIRC most unix systems have been following the weak host model. As mentioned the weak model has a lot of benefits. I see no point in changing this. -- :wq Claudio
Re: Strong Host Model in OpenBSD network stack
On Thu, Oct 17, 2019 at 10:33:41PM -0600, Theo de Raadt wrote: > > Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > > replies immediately. > > > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > > interface was contacted. > > How many users set those variables? > > A global seems this is a misguided place to establish such a policy. > > If it was good and neccessary for everyone on all interfaces and had no > downsides, they would have turned it on. But they didn't. > > A similar feature "urpf-failed" which is more nuanced is available in > pf.conf, and you can properly use it on a per-interface basis, also > selecting to do so based un other per-rule options, rather than having > a 'global rule'. > > Something blocked FreeBSD or NetBSD from turning this into the default. > What was that reason -- was it too damaging? > > (I'm going to assume the people with so-called 'strong' views didn't win > the battle, and the so-called 'weak' view pervailed, probably because > the 'strong' option created breakage and prevents the dominant > operational model of Getting-Shit-Done. That's why I ask how many > people in real life subscribe the 'strong' view by turning on this > option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, > everyone is so busy getting on about their lives they don't flip any > knobs which don't provide an immediately confirmable and neccessary > value). > > from source port source os source to dest port dest > This rule applies only to packets with the specified source and > destination addresses and ports. > > Addresses can be specified in CIDR notation (matching netblocks), > as symbolic host names, interface names or interface group names, > or as any of the following keywords: > > any Any address. > no-route Any address which is not currently routable. > route label Any address matching the given route(8) label. > self Expands to all addresses assigned to all interfaces. >Any address matching the given table. > urpf-failed Any source address that fails a unicast reverse path > forwarding (URPF) check, i.e. packets coming in on > an interface other than that which holds the route > back to the packet's source address. > > Convince us we should change to the strong model, and I'll embrace it. > > You won't convince us to make a global which people don't understand... > This "strong" model is a bad fit for routers. When this model is needed we have pf (antispoof or urpf-failed). Alternatively rdomains can be used (put a network interface with management services on it in a separate rdomain). Remi
Re: Strong Host Model in OpenBSD network stack
> Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > replies immediately. > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > interface was contacted. How many users set those variables? A global seems this is a misguided place to establish such a policy. If it was good and neccessary for everyone on all interfaces and had no downsides, they would have turned it on. But they didn't. A similar feature "urpf-failed" which is more nuanced is available in pf.conf, and you can properly use it on a per-interface basis, also selecting to do so based un other per-rule options, rather than having a 'global rule'. Something blocked FreeBSD or NetBSD from turning this into the default. What was that reason -- was it too damaging? (I'm going to assume the people with so-called 'strong' views didn't win the battle, and the so-called 'weak' view pervailed, probably because the 'strong' option created breakage and prevents the dominant operational model of Getting-Shit-Done. That's why I ask how many people in real life subscribe the 'strong' view by turning on this option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, everyone is so busy getting on about their lives they don't flip any knobs which don't provide an immediately confirmable and neccessary value). from source port source os source to dest port dest This rule applies only to packets with the specified source and destination addresses and ports. Addresses can be specified in CIDR notation (matching netblocks), as symbolic host names, interface names or interface group names, or as any of the following keywords: any Any address. no-route Any address which is not currently routable. route label Any address matching the given route(8) label. self Expands to all addresses assigned to all interfaces. Any address matching the given table. urpf-failed Any source address that fails a unicast reverse path forwarding (URPF) check, i.e. packets coming in on an interface other than that which holds the route back to the packet's source address. Convince us we should change to the strong model, and I'll embrace it. You won't convince us to make a global which people don't understand...
Re: Strong Host Model in OpenBSD network stack
Exactly, I tried the same using FreeBSD and NetBSD.
Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo
replies immediately.
On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same
behaviour like FreeBSD. No replies anymore, whenever the "wrong"
interface was contacted.
So basically my question is which model OpenBSD is following. If it's
supposed to use the "strong model" as default, I'd have expected that it
would behave like Free-/NetBSD with check_interface/checkinterface set
to 1. If OpenBSD uses the "weak model" by default then the observed
behaviour is as expected.
However I was wondering that there is no kernel parameter at all to
adjust this behaviour.
Thanks,
Bastian
Am 18.10.19 um 02:03 schrieb Aaron Mason:
> Bastian
>
> Did you perform this same test in FreeBSD/NetBSD? What were your results?
>
> Seems to me that the results you got in test 2 are entirely consistent
> with normal behaviour - you are routing packets to the 10.0.0.0/24
> network via 192.168.100.1, so it will return a ping from 10.0.0.97 -
> the other interface on VM1 - as the packet was passed from em0 to em1,
> from which the reply was initiated.
>
> Of course, I could be wrong. if you haven't already done so, try the
> same tests in (Free|Net)BSD with net.inet.ip.check_interface set to 1
> and see what you get.
>
> On Fri, Oct 18, 2019 at 6:53 AM Bastian Kanbach wrote:
>> Hello,
>>
>> recently I was performing some checks that relate to the "Strong Host
>> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
>> different than I expected. I always assumed that the network stack of
>> OpenBSD was following the "Strong Host Model", but I might be wrong with
>> that:
>>
>> Basically the Strong Host Model means that the network stack "accepts
>> locally destined packets if the destination IP address in the packet
>> matches an IP address assigned to the network interface on which the
>> packet was received."
>>
>> FreeBSD and NetBSD have a sysctl property for this, called
>> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
>> However for OpenBSD I haven't seen such a property at all.
>>
>>
>> Basically my setup consisted of the following virtual machines and
>> network interfaces (IP-Forwarding disabled):
>>
>>
>> VM 1 (OpenBSD 6.5):
>>
>> em0: 192.168.100.1/24 ("Internal Network")
>>
>> em1: 10.0.0.97/24 ("NAT")
>>
>>
>> VM 2 (Ubuntu Server 18.10):
>>
>> ens33: 192.168.100.2/24 ("Internal Network")
>>
>>
>>
>>
>>
>> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
>> interfaces are associated with the same Virtualbox network, and both IP
>> addresses are part of the same /24 subnet.
>>
>> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
>> addresses are part of different subnets and no routes were configured.
>>
>>
>> Then I performed 2 tests:
>>
>>
>> Test 1:
>>
>> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
>> packet was NOT answered by VM1.
>>
>>
>> Test 2:
>>
>> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
>> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
>> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
>> MAC address of interface em0).
>>
>>
>> While the behaviour of Test 1 indicates that the Strong Host Model is
>> followed, Test 2 shows the behaviour of a "Weak Host Model".
>>
>>
>> What of both is actually supposed to be the default for OpenBSD? Is
>> there any kernel parameter to control these behaviours, like
>> net.inet.ip.check_interface for FreeBSD or NetBSD?
>>
>>
>> Thanks,
>>
>> Bastian
>>
>>
>>
>>
>
Re: Strong Host Model in OpenBSD network stack
Bastian
Did you perform this same test in FreeBSD/NetBSD? What were your results?
Seems to me that the results you got in test 2 are entirely consistent
with normal behaviour - you are routing packets to the 10.0.0.0/24
network via 192.168.100.1, so it will return a ping from 10.0.0.97 -
the other interface on VM1 - as the packet was passed from em0 to em1,
from which the reply was initiated.
Of course, I could be wrong. if you haven't already done so, try the
same tests in (Free|Net)BSD with net.inet.ip.check_interface set to 1
and see what you get.
On Fri, Oct 18, 2019 at 6:53 AM Bastian Kanbach wrote:
>
> Hello,
>
> recently I was performing some checks that relate to the "Strong Host
> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
> different than I expected. I always assumed that the network stack of
> OpenBSD was following the "Strong Host Model", but I might be wrong with
> that:
>
> Basically the Strong Host Model means that the network stack "accepts
> locally destined packets if the destination IP address in the packet
> matches an IP address assigned to the network interface on which the
> packet was received."
>
> FreeBSD and NetBSD have a sysctl property for this, called
> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
> However for OpenBSD I haven't seen such a property at all.
>
>
> Basically my setup consisted of the following virtual machines and
> network interfaces (IP-Forwarding disabled):
>
>
> VM 1 (OpenBSD 6.5):
>
> em0: 192.168.100.1/24 ("Internal Network")
>
> em1: 10.0.0.97/24 ("NAT")
>
>
> VM 2 (Ubuntu Server 18.10):
>
> ens33: 192.168.100.2/24 ("Internal Network")
>
>
>
>
>
> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
> interfaces are associated with the same Virtualbox network, and both IP
> addresses are part of the same /24 subnet.
>
> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
> addresses are part of different subnets and no routes were configured.
>
>
> Then I performed 2 tests:
>
>
> Test 1:
>
> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
> packet was NOT answered by VM1.
>
>
> Test 2:
>
> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
> MAC address of interface em0).
>
>
> While the behaviour of Test 1 indicates that the Strong Host Model is
> followed, Test 2 shows the behaviour of a "Weak Host Model".
>
>
> What of both is actually supposed to be the default for OpenBSD? Is
> there any kernel parameter to control these behaviours, like
> net.inet.ip.check_interface for FreeBSD or NetBSD?
>
>
> Thanks,
>
> Bastian
>
>
>
>
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Strong Host Model in OpenBSD network stack
Hello,
recently I was performing some checks that relate to the "Strong Host
Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
different than I expected. I always assumed that the network stack of
OpenBSD was following the "Strong Host Model", but I might be wrong with
that:
Basically the Strong Host Model means that the network stack "accepts
locally destined packets if the destination IP address in the packet
matches an IP address assigned to the network interface on which the
packet was received."
FreeBSD and NetBSD have a sysctl property for this, called
"net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
However for OpenBSD I haven't seen such a property at all.
Basically my setup consisted of the following virtual machines and
network interfaces (IP-Forwarding disabled):
VM 1 (OpenBSD 6.5):
em0: 192.168.100.1/24 ("Internal Network")
em1: 10.0.0.97/24 ("NAT")
VM 2 (Ubuntu Server 18.10):
ens33: 192.168.100.2/24 ("Internal Network")
As expected, ens33 of VM2 can communicate with em0 of VM1, since both
interfaces are associated with the same Virtualbox network, and both IP
addresses are part of the same /24 subnet.
ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
addresses are part of different subnets and no routes were configured.
Then I performed 2 tests:
Test 1:
Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
packet was NOT answered by VM1.
Test 2:
Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
MAC address of interface em0).
While the behaviour of Test 1 indicates that the Strong Host Model is
followed, Test 2 shows the behaviour of a "Weak Host Model".
What of both is actually supposed to be the default for OpenBSD? Is
there any kernel parameter to control these behaviours, like
net.inet.ip.check_interface for FreeBSD or NetBSD?
Thanks,
Bastian
