-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My log is being spammed by these two messages: <0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1 192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode. System is still 15.2 (on both). What should I do? - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcMnqxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVbzkAnj1jML0siEmJ9O5BcR8r bw8d6kBGAJ48meWbLG+vj2Bj3FULUX9GzROjiQ== =2iCA -----END PGP SIGNATURE-----
On 2021-12-22 7:27 a.m., Carlos E. R. wrote:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
System is still 15.2 (on both).
What should I do?
Upgrade to 15.3? ;)
On 22/12/2021 14.49, Darryl Gregorash wrote:
On 2021-12-22 7:27 a.m., Carlos E. R. wrote:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
System is still 15.2 (on both).
What should I do?
Upgrade to 15.3? ;)
Do you guarantee that the error will disappear there? Because what I'm doing right now is testing the upgrade in a virtual machine. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-12-22 07:53, Carlos E.R. wrote:
On 22/12/2021 14.49, Darryl Gregorash wrote:
On 2021-12-22 7:27 a.m., Carlos E. R. wrote:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
System is still 15.2 (on both).
What should I do?
Upgrade to 15.3? ;)
Do you guarantee that the error will disappear there?
Because what I'm doing right now is testing the upgrade in a virtual machine.
No, I can't, but if you do and the problem persists, then you will be able to file a legitimate bug report. 15.2 goes out of support in 9 days, so chances are not many are really interested in resolving this issue in that release.
On 22/12/2021 15.16, Darryl Gregorash wrote:
On 2021-12-22 07:53, Carlos E.R. wrote:
On 22/12/2021 14.49, Darryl Gregorash wrote:
On 2021-12-22 7:27 a.m., Carlos E. R. wrote:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
System is still 15.2 (on both).
What should I do?
Upgrade to 15.3? ;)
Do you guarantee that the error will disappear there?
Because what I'm doing right now is testing the upgrade in a virtual machine.
No, I can't, but if you do and the problem persists, then you will be able to file a legitimate bug report. 15.2 goes out of support in 9 days, so chances are not many are really interested in resolving this issue in that release.
Ok, then you are assuming it is a bug, not a problem. I was simply asking, maybe it is known, some wrong configuration on my side. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am 22.12.21 um 14:27 schrieb Carlos E. R.:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
Does it say something about martians (no kidding!), too? If so, you may have a duplicate MAY address in your network. If martians are logged, you can see with 'sysctl -a | grep martians'.
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
System is still 15.2 (on both).
What should I do?
-- Cheers
Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 22/12/2021 15.30, Keine Eile wrote:
Am 22.12.21 um 14:27 schrieb Carlos E. R.:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
Does it say something about martians (no kidding!), too? If so, you may have a duplicate MAY address in your network.
No, it doesn't.
If martians are logged, you can see with 'sysctl -a | grep martians'.
Telcontar:~ # sysctl -a | grep martians net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.eth0.log_martians = 1 net.ipv4.conf.lo.log_martians = 1 net.ipv4.conf.vboxnet0.log_martians = 1 Telcontar:~ # 192.168.2.1 is the address of the virtual machine, network in VBox bridge mode, and 192.168.1.14 is the host machine, the other half of the bridged interface. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
A redirect is a routing instruction "icmp redirect" that says "go this way for that address". There is a kernel setting wrt accepting redirects or not.
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
What exactly have you bridged? which networks? The redirect is 192.168.1.1 telling telcontar to go direct instead of going via the router (at 192.168.1.1)
What should I do?
I think maybe revisit your network config. Telcontar thinks it has to go via the router to get to 192.168.2.x, but the router thinks not. -- Per Jessen, Zürich (0.2°C)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-12-22 at 16:04 +0100, Per Jessen wrote:
Carlos E. R. wrote:
My log is being spammed by these two messages:
<0.6> 2021-12-22T14:23:10.886668+01:00 Telcontar kernel - - - [34111.261316] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:10.886682+01:00 Telcontar kernel - - - [34111.261316] Advised path = 192.168.1.14 -> 192.168.2.1 <0.6> 2021-12-22T14:23:11.879169+01:00 Telcontar kernel - - - [34112.251659] IPv4: Redirect from 192.168.1.1 on eth0 about 192.168.2.1 ignored <0.6> 2021-12-22T14:23:11.879183+01:00 Telcontar kernel - - - [34112.251659] Advised path = 192.168.1.14 -> 192.168.2.1
A redirect is a routing instruction "icmp redirect" that says "go this way for that address". There is a kernel setting wrt accepting redirects or not.
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
What exactly have you bridged? which networks?
I don't know, I didn't do it. Virtualbox does it. Virtual box has several modes: NAT Bridged adapter Internal Network Host-only adapter Generic driver Nat network Not attached Default mode is "NAT". In this mode I can connect (ssh) from client to host, but not the other way. I don't remember this moment the IP I got, perhaps a 10.something. So I have changed to bridged mode. Prior to doing this, in the router I have done a change. The DHCP range was 192.168.1.132 to 199, and I just changed it to 192.168.2.1 to 254. The mask on the router is 255.255.0.0 Thus the guest gets this: Eleanor152:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 100 0 0 eth0 Eleanor152:~ #
The redirect is 192.168.1.1 telling telcontar to go direct instead of going via the router (at 192.168.1.1)
What should I do?
I think maybe revisit your network config. Telcontar thinks it has to go via the router to get to 192.168.2.x, but the router thinks not.
To the router, both host and client are the same cable, it is absurd to go via router. Telcontar:~ # route çKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Telcontar:~ # I suspect that the last line is the problem, mask should perhaps be 255.255.0.0, same as in client. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcOH3hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV2msAn29f0oSFwujX+NLQft0y psqD5rkRAJ4vMUJyBmwXQo5PGiJPNYHWX9H4NA== =cqVl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-12-22 at 21:17 +0100, Carlos E. R. wrote:
On Wednesday, 2021-12-22 at 16:04 +0100, Per Jessen wrote:
Carlos E. R. wrote:
My log is being spammed by these two messages:
...
What should I do?
I think maybe revisit your network config. Telcontar thinks it has to go via the router to get to 192.168.2.x, but the router thinks not.
To the router, both host and client are the same cable, it is absurd to go via router.
Telcontar:~ # route çKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Telcontar:~ #
I suspect that the last line is the problem, mask should perhaps be 255.255.0.0, same as in client.
Trying to reconfigure this, I get a YaST error: Parse error while reading file /etc/sysctl.d/90-nfs.conf YaST cannot continue and will quit. Possible causes and remedies: 1. You made a mistake when changing the file by hand, the syntax is invalid. Try reverting the changes. 2. The syntax is in fact valid but YaST does not recognize it. Please report a YaST bug. 3. YaST made a mistake and wrote invalid syntax earlier. Please report a YaST bug. Caller: /usr/lib64/ruby/gems/2.5.0/gems/cfa-1.0.2/lib/cfa/augeas_parser.rb:458:in `report_activity_error!' Details: Augeas parsing error: Iterated lens matched less than it should at /etc/sysctl.d/90-nfs.conf:1:2, lens /usr/share/augeas/lenses/dist/sysctl.aug:38.10-.52: And aborts. :-( Ok, trying manually. /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.1.14/24' <==== should be /16 MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' PREFIXLEN='24' REMOTE_IPADDR='' STARTMODE='auto' ZONE='external' And then restart network - but can't risk it now, guest is running a zypper dup. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcOKeBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVJt0An1qrzZWwjhRFbwpEus+c lQOlFViFAJ9zqUtnckGhUZYsUCO5buRLvIUcbg== =AeHM -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Ok, trying manually.
/etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.1.14/24' <==== should be /16 MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' PREFIXLEN='24'
remove that line too. -- Per Jessen, Zürich (-2.0°C)
Carlos E. R. wrote:
What exactly have you bridged? which networks?
I don't know, I didn't do it. Virtualbox does it.
That is not a good starting point :-)
Virtual box has several modes:
NAT Bridged adapter Internal Network Host-only adapter Generic driver Nat network Not attached
Default mode is "NAT". In this mode I can connect (ssh) from client to host, but not the other way.
Right, much the same with everyone's fibre or adsl router setup.
I don't remember this moment the IP I got, perhaps a 10.something.
So I have changed to bridged mode.
Bridging is connecting two physically separate networks to make them appear as if they are one. That could work for you I think, but not if you are using two separate subnets, i.e. 192.168.1.0/24 and 192.168.2.0/24.
Prior to doing this, in the router I have done a change. The DHCP range was 192.168.1.132 to 199, and I just changed it to 192.168.2.1 to 254. The mask on the router is 255.255.0.0
Okay, so you have one subnet 192.168.0.0/16. That's fine, even if not necessary.
Thus the guest gets this:
Eleanor152:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 100 0 0 eth0 Eleanor152:~ #
Yup, looks good.
I think maybe revisit your network config. Telcontar thinks it has to go via the router to get to 192.168.2.x, but the router thinks not.
To the router, both host and client are the same cable, it is absurd to go via router.
Depends on your config. On Telcontar, what does 'ip route get 192.168.2.1' say?
Telcontar:~ # route çKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Telcontar:~ #
I suspect that the last line is the problem, mask should perhaps be 255.255.0.0, same as in client.
Of course it should, you have changed your subnet. Because 192.168.2.1 does not match what is available on eth0, it has to use the default gateway. -- Per Jessen, Zürich (-1.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-12-22 at 21:40 +0100, Per Jessen wrote:
Carlos E. R. wrote:
What exactly have you bridged? which networks?
I don't know, I didn't do it. Virtualbox does it.
That is not a good starting point :-)
Sorry :-) I mean it is not my personal doing, something in vbox does it automatically.
Virtual box has several modes:
NAT Bridged adapter Internal Network Host-only adapter Generic driver Nat network Not attached
Default mode is "NAT". In this mode I can connect (ssh) from client to host, but not the other way.
Right, much the same with everyone's fibre or adsl router setup.
Yep. It is the default mode, and it is confusing coming from VMware.
I don't remember this moment the IP I got, perhaps a 10.something.
So I have changed to bridged mode.
Bridging is connecting two physically separate networks to make them appear as if they are one. That could work for you I think, but not if you are using two separate subnets, i.e. 192.168.1.0/24 and 192.168.2.0/24.
But the term is also used in virtualization, meaning using the same cable on two machines. The same ethernet interface with two addresses.
Prior to doing this, in the router I have done a change. The DHCP range was 192.168.1.132 to 199, and I just changed it to 192.168.2.1 to 254. The mask on the router is 255.255.0.0
Okay, so you have one subnet 192.168.0.0/16. That's fine, even if not necessary.
I feel I need a larger DHCP pool. We talked about this maybe a year ago, just that I did not make the step till today. Which is why the mask was changed already to /16.
Thus the guest gets this:
Eleanor152:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 100 0 0 eth0 Eleanor152:~ #
Yup, looks good.
I think maybe revisit your network config. Telcontar thinks it has to go via the router to get to 192.168.2.x, but the router thinks not.
To the router, both host and client are the same cable, it is absurd to go via router.
Depends on your config.
Hardware wise, it would be absurd to travel more distance.
On Telcontar, what does 'ip route get 192.168.2.1' say?
Telcontar:~ # route çKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Telcontar:~ #
I suspect that the last line is the problem, mask should perhaps be 255.255.0.0, same as in client.
Of course it should, you have changed your subnet. Because 192.168.2.1 does not match what is available on eth0, it has to use the default gateway.
See the other later post, I was trying to do that, YaST crashed. I'm changing in "/etc/sysconfig/network/ifcfg-eth0": BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.1.14/24' MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' PREFIXLEN='24' REMOTE_IPADDR='' STARTMODE='auto' ZONE='external' to /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.1.14/16' MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' PREFIXLEN='24' REMOTE_IPADDR='' STARTMODE='auto' ZONE='external' What about "PREFIXLEN='24'", should be 16? Waiting for a chance to restart the network. You say "remove that line too.". What line? :-? - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcOQmRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNJgAoJLfT7yXzJlEYWOTt65y GdWLGDsRAJ4jyv0rvwRvJip9t2xoIhvnygQf6A== =tTz5 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-12-22 at 21:54 +0100, Carlos E. R. wrote:
On Wednesday, 2021-12-22 at 21:40 +0100, Per Jessen wrote:
Carlos E. R. wrote:
On Telcontar, what does 'ip route get 192.168.2.1' say?
Forgot this question. Telcontar:~ # ip route get 192.168.2.1 192.168.2.1 via 192.168.1.1 dev eth0 src 192.168.1.14 uid 0 cache Telcontar:~ # now I have: BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.1.14/16' MTU='' NAME='RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' NETWORK='' PREFIXLEN='16' REMOTE_IPADDR='' STARTMODE='auto' ZONE='external' File /etc/sysconfig/network/ifcfg-eth0 saved Telcontar:~ # rcnetwork restart Telcontar:~ # ip route get 192.168.2.1 192.168.2.1 dev eth0 src 192.168.1.14 uid 0 cache Telcontar:~ # Telcontar:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Telcontar:~ # Starting virtual machine now. [...] The error message is gone. Thanks :-) <3.6> 2021-12-22T22:10:08.314679+01:00 Telcontar systemd 1 - - Stopped wicked managed network interfaces. <3.6> 2021-12-22T22:10:08.315865+01:00 Telcontar systemd 1 - - Starting wicked managed network interfaces... <0.6> 2021-12-22T22:10:08.395167+01:00 Telcontar kernel - - - [62128.885503] Generic Realtek PHY r8169-2200:00: attached PHY driver [Generic Realtek PHY] (mii_bus:phy_addr=r8169-2200:00, irq=IGNORE) <0.6> 2021-12-22T22:10:08.507167+01:00 Telcontar kernel - - - [62128.997573] r8169 0000:22:00.0 eth0: Link is Down <0.6> 2021-12-22T22:10:12.175173+01:00 Telcontar kernel - - - [62132.666064] r8169 0000:22:00.0 eth0: Link is Up - 1Gbps/Full - flow control off <0.6> 2021-12-22T22:10:12.175186+01:00 Telcontar kernel - - - [62132.666075] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready <3.6> 2021-12-22T22:10:12.203360+01:00 Telcontar avahi-daemon 1805 - - Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.14. <3.6> 2021-12-22T22:10:12.203517+01:00 Telcontar avahi-daemon 1805 - - New relevant interface eth0.IPv4 for mDNS. <3.6> 2021-12-22T22:10:12.203596+01:00 Telcontar avahi-daemon 1805 - - Registering new address record for 192.168.1.14 on eth0.IPv4. <3.6> 2021-12-22T22:10:13.259286+01:00 Telcontar avahi-daemon 1805 - - Joining mDNS multicast group on interface eth0.IPv6 with address fe80::2d8:61ff:fea1:5abd. <3.6> 2021-12-22T22:10:13.259524+01:00 Telcontar avahi-daemon 1805 - - New relevant interface eth0.IPv6 for mDNS. <3.6> 2021-12-22T22:10:13.259649+01:00 Telcontar avahi-daemon 1805 - - Registering new address record for fe80::2d8:61ff:fea1:5abd on eth0.*. <3.6> 2021-12-22T22:10:13.360942+01:00 Telcontar wicked 23028 - - lo setup-in-progress <3.6> 2021-12-22T22:10:13.361114+01:00 Telcontar wicked 23028 - - eth0 up <3.6> 2021-12-22T22:10:13.362687+01:00 Telcontar systemd 1 - - Started wicked managed network interfaces. <0.4> 2021-12-22T22:11:40.943172+01:00 Telcontar kernel - - - [62221.435574] vboxdrv: 0000000000000000 VMMR0.r0 <0.4> 2021-12-22T22:11:41.031176+01:00 Telcontar kernel - - - [62221.523647] vboxdrv: 0000000000000000 VBoxDDR0.r0 <0.4> 2021-12-22T22:11:41.111172+01:00 Telcontar kernel - - - [62221.603326] VBoxNetFlt: attached to 'eth0' / 00:d8:61:a1:5a:bd <0.4> 2021-12-22T22:11:41.119181+01:00 Telcontar kernel - - - [62221.609431] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0) <0.6> 2021-12-22T22:11:41.119194+01:00 Telcontar kernel - - - [62221.611553] device eth0 entered promiscuous mode - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcOWRxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVskoAmwbamQk1GEdY52sPGqxd W9VhBXVeAJ4kyKZzEvXRzVTfd9V7JrID5oxT8w== =jVWt -----END PGP SIGNATURE-----
Am 22.12.2021 um 14:27 schrieb Carlos E. R.:
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
Don't run the interface in bridge mode but inside the VM on a different subnet - you have to use the NATBRIDGE for that kind of stuff. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-12-22 at 17:08 +0100, Mathias Homann wrote:
Am 22.12.2021 um 14:27 schrieb Carlos E. R.:
192.168.2.1 belongs to a new virtual machine running in VBox, network in bridge mode.
Don't run the interface in bridge mode but inside the VM on a different subnet - you have to use the NATBRIDGE for that kind of stuff.
Does that allow me to ssh in both directions, host to guest, guest to host? - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcOI4hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVSksAn2rzPN8aNPv5KRq9LOQ1 YUrOPUjUAJ9Cp/Y5I6/Zuckmp/xrtPf/PeXh6A== =h+Ai -----END PGP SIGNATURE-----
Am 22.12.2021 um 21:21 schrieb Carlos E. R.:
On Wednesday, 2021-12-22 at 17:08 +0100, Mathias Homann wrote:
Am 22.12.2021 um 14:27 schrieb Carlos E. R.:
192.168.2.1 belongs to a new virtual machine running in VBox,
network in
bridge mode.
Don't run the interface in bridge mode but inside the VM on a different subnet - you have to use the NATBRIDGE for that kind of stuff.
Does that allow me to ssh in both directions, host to guest, guest to host?
no. if you want that, your VM has to be on the regular bridge as it is now, but then your VM needs to have an IP address from your real network. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 22/12/2021 23.43, Mathias Homann wrote:
Am 22.12.2021 um 21:21 schrieb Carlos E. R.:
On Wednesday, 2021-12-22 at 17:08 +0100, Mathias Homann wrote:
Am 22.12.2021 um 14:27 schrieb Carlos E. R.:
192.168.2.1 belongs to a new virtual machine running in VBox,
network in
bridge mode.
Don't run the interface in bridge mode but inside the VM on a different subnet - you have to use the NATBRIDGE for that kind of stuff.
Does that allow me to ssh in both directions, host to guest, guest to host?
no.
Ah. I feared so.
if you want that, your VM has to be on the regular bridge as it is now, but then your VM needs to have an IP address from your real network.
Yes, that's exactly what I have now. I would prefer to have connectivity between host and guest only, not from outside the host. I had that with vmware, but apparently it is not possible with virtualbox. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
On 22/12/2021 23.43, Mathias Homann wrote:
if you want that, your VM has to be on the regular bridge as it is now, but then your VM needs to have an IP address from your real network.
Yes, that's exactly what I have now.
I would prefer to have connectivity between host and guest only, not from outside the host. I had that with vmware, but apparently it is not possible with virtualbox.
Just use a firewall to restrict what the guest is able to do. -- Per Jessen, Zürich (0.6°C)
On 23/12/2021 09.13, Per Jessen wrote:
Carlos E. R. wrote:
On 22/12/2021 23.43, Mathias Homann wrote:
if you want that, your VM has to be on the regular bridge as it is now, but then your VM needs to have an IP address from your real network.
Yes, that's exactly what I have now.
I would prefer to have connectivity between host and guest only, not from outside the host. I had that with vmware, but apparently it is not possible with virtualbox.
Just use a firewall to restrict what the guest is able to do.
I don't think that would work. A firewall on the host, when the guest is bridged on the same ethernet, bypasses the host firewall. It would has to be a firewall in the guest, as any other independent machine. This is a bad idea when the guest is Windows, for example. The vmware method is much better. The guest is in an independent network interface, totally invisible from the LAN, only from the host. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
On 23/12/2021 09.13, Per Jessen wrote:
Carlos E. R. wrote:
On 22/12/2021 23.43, Mathias Homann wrote:
if you want that, your VM has to be on the regular bridge as it is now, but then your VM needs to have an IP address from your real network.
Yes, that's exactly what I have now.
I would prefer to have connectivity between host and guest only, not from outside the host. I had that with vmware, but apparently it is not possible with virtualbox.
Just use a firewall to restrict what the guest is able to do.
I don't think that would work. A firewall on the host, when the guest is bridged on the same ethernet, bypasses the host firewall.
Depends on your setup of course, but it works for me (with xen). You could also look at using ebtables.
It would has to be a firewall in the guest, as any other independent machine. This is a bad idea when the guest is Windows, for example.
The vmware method is much better.
The guest is in an independent network interface, totally invisible from the LAN, only from the host.
The hypervisors all use the same networking, more or less - some of them just wrap it in GUIs or scripts. xen, for instance, does not provide any "method" at all, it's just standard networking setup. -- Per Jessen, Zürich (6.8°C)
On 23/12/2021 17.04, Andrei Borzenkov wrote:
On 23.12.2021 13:24, Carlos E. R. wrote:
The vmware method is much better.
The guest is in an independent network interface, totally invisible from the LAN, only from the host.
Which is exactly what host only networking in virtualbox does.
Ah, thanks. I'll try that :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 23/12/2021 19.54, Carlos E. R. wrote:
On 23/12/2021 17.04, Andrei Borzenkov wrote:
On 23.12.2021 13:24, Carlos E. R. wrote:
The vmware method is much better.
The guest is in an independent network interface, totally invisible from the LAN, only from the host.
Which is exactly what host only networking in virtualbox does.
Ah, thanks. I'll try that :-)
Mmm. I can connect from host to guest fine, but not from guest to host. Says "Network unreachable" -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Darryl Gregorash -
Keine Eile -
Mathias Homann -
Per Jessen