ICMP Signal works, 5 seconds later it doesn't work?

SUSE Product Topics SLES Networking
1

Hi Forum Users,

My System is a physical Server with Suse Enterprise Server, and a virtual Machine with a Ubuntu Server.

I have a successfully ICMP signal which forwarding in my virtual machine in the config below. A few minutes later the same configuration doesn’t work.

my config about my Problem is following:

pyhsical machine: eth1; > virtual bridge: br0, > virtual nic: vnet1 (subnet 1)

                             this going to transfer in eth0 in the virtual machine

                                   FORWARDING to:

                             eth1 in the virtual machine

then through ; virtual nic: vnet0; > virtual bridge: br1; > physical machine: eth0 (subnet2)

I explain:

When I use following command: ping -I 192.168.2.x 192.168.178.y

I ping from one bridge to the other one. It’s work and it’s FORWARDING.

But now it’s away again.

I don’t no why?

Now I can ping from br0 to br1 without it recognized from my forwarding iptable rule in my virtual machine. And both br0 and br1 are in different subnets.

I have no forwarding active in my physical server.

My bridges and nics (virtual and physical) are up. My bridges consist of both nics. I have STP enabled. My iptables in the SLES are empty.

About my routes I’m not so sure, but between the success and the fail (and this more times) I didn’t change anything.

Thank you for reading,
Flo

2

Hi Flo,

I suggest you run tcpdump on the involved interfaces, to see where (and how far) things are going. Also, is there anything in syslog (/var/log/mesages) on the machines?

Which SLES version is this? And it seems you’re running VMware, is that correct?

Regards,
Jens

3

Hi Jens and Users,

thank you for reply.

I use SLES 12, and my VM works under KVM, qemu, Virtual Machine Manager.

Sorry for the /var/log/messages. I don’t know how can I extract the network outputs.
Is it helpful?
But I have start my Server, and then I have try to communicate.

The messages are in the attachment.

And the tcpdump files likewise.

I don’t know why there is my Router Adress (192.168.2.1) in tcp dump, I have not input it?

Thank you,
Flo

4

Hi,

sorry Jens!

In the attachment I have a better formated log messages file.

Thank you,
Flo

5

Hi Flo,

ping -I 192.168.2.x 192.168.178.y
I don’t know why there is my Router Adress (192.168.2.1) in tcp dump, I have not input it

I guess we need to sort out your network setup then, first. Does your host (the machine you’re running “ping” from) have an interface in the 192.168.178.y network? Because if net, it will have to use a router to have the packet forwarded. And I guess that 192.168.2.1 is the default router of the host machine.

Secondly, I don’t see any ICMP echo requests in the dumps. This is probably because the packets aren’t sent via the br0 device, but via the physical interface that has an IP address in the network connecting to the router.

Regards,
Jens

6

Hi Jens,

thank you for reply.

For the first question: The host, where I ping from have two Interfaces with IP addresses:

The first have 192.168.178.x and the second have: 192.168.2.x

First consist of: eth1 (physical), br0 and vnet1. And in this config just br0 have an IP address (192.168.2.x).

                          The bridge connect eth1 and vnet1.

Second consist of: eth0 (physical), br1 and vnet0. And in this config just br1 have an IP address (192.169.178.x).

                           The bridge connect eth0 and vnet0.

I have no default router active. Not in the GUI and not in the file: /etc/sysconfig/network/routes.
But earlier I had one and this was: 192.168.2.1.

Second: This extract shows at least a ICMP action in the dump file:

linux-jwys.site > 192.168.2.1: ICMP linux-jwys.site udp port netbios-ns unreachable, length 86
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)

But I don’t know exactly what this means.

I don’t know but I want to try with setting the right routes to solve the problem.

If you have some suggestions how I can connect the nics with routes I will be happy.

At the edge, can the many error messageges about „dconf“ in the log messages a coherence with this network problem?

Thank you,
Flo

7

Hi Flo,
in your opening message you wrote

this going to transfer in eth0 in the virtual machine
FORWARDING to:
eth1 in the virtual machine

but I could not find out how you’re forwarding - is it bridging or routing?

And if the VM is doing routing, then the IP addresses of the VM’s interfaces would be relevant, too.

So what I concluded from your traces and descriptions is

  • host:eth0 (connecting to no external network), connected to host:br1 (IP 192.168.178.37), connecting to vnet0, connecting to VM:eth1
  • host:eth1 (connecting to an external network 192.168.2.x), connected to host:br (IP 192.168.2.9), connecting to vnet1, connecting to VM:eth0

The output of “ip addr list; brtcl show; netstat -rn” from the host might help to verify these assumptions.

user@host # ping -I 192.168.2.9 192.168.178.37

A problem I see is that 192.168.178.37, which you’re trying to ping , is a local address to the machine you’re pinging from. I wouldn’t expect any ICMP echo request to leave the machine at all. OTOH, you’re trying to ping via a different interface, so the ICMP echo request might get ignored. (I would have to dig up the details of that situation, IP stack wise).

I have no default router active.[…] But earlier I had one

Please use “netstat -rn” to verify the situation - looking at the files will only show you what the system would try to configure upon the next network (re)start.

Second: This extract shows at least a ICMP action in the dump file:
linux-jwys.site > 192.168.2.1: ICMP linux-jwys.site udp port netbios-ns unreachable, length 86
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)

But I don’t know exactly what this means.

What you’re actually looking for are “ICMP echo requests” and “ICMP echo replies”.

12:51:19.615455 IP yourhost > someotherhost: ICMP echo request, id 5006, seq 1, length 64 12:51:19.618148 IP someotherhost > yourhost: ICMP echo reply, id 5006, seq 1, length 64
Your trace shows a “port unreachable” notification, send by linux-jwys.site to the site router (192.168.2.1), telling that no-one is listening on the port for “netbios-ns”.

What are you trying to achieve with your setup and tests? Your test violates some basic operations principles.

  • pinging an address in a different subnet requires a router
  • pinging local addresses via a different interface may well fail (I’d have to look that up)

a - if the VM is a test for a bridge, then create a second VM and let that one have an 192.168.2.x address, then run your ping test from the host. You should not even need to specify the source adapter, as the stack ought to pick that automatically.

b - if the VM is a test for a router: then it needs to be set up properly with IP addresses, forwarding activated, and you’d need a route on the host. And again use a second VM as the actual target, and avoid having an interface on the host within the same subnet.

Either way, the output of “ip addr list; brtcl show; netstat -rn;sysctl -a|grep forwarding” from the VM might help to understand that part of the setup.

Regards,
Jens

8

[ATTACH]119[/ATTACH][ATTACH]120[/ATTACH][ATTACH]121[/ATTACH]Hi Jens,

The description for my statement,

this going to transfer in eth0 in the virtual machine
FORWARDING to:
eth1 in the virtual machine

is following: Is should be a router, for a Intrusion Prevention System (Snort).

With my iptables I would catch my (in the moment) ICMP Signal in the FORWARDING chain.

With the command: iptables -L -v, I get displayed the bytes which were FORWARDING through the chain.

My two virtual nics (vnet) in my Virtual Machine have the IP – adresses:

 192.168.178.24 and 192.168.2.17

A problem I see is that 192.168.178.37, which you’re trying to ping , is a local address to the machine you’re pinging from. I wouldn’t expect any ICMP echo request to leave the machine at all. OTOH, you’re trying to ping via a different interface, so the ICMP echo request might get ignored. (I would have to dig up the details of that situation, IP stack wise).

Yes I do. I tried to ping from my Laptop too, but in my two or three succesfull situations, I have use the ping from this host. Where all this is configured. In this situations my FORWARDING chain registered traffic. But it 's away in short times.

With the netstat -rn output (from host and from VM) in the moment I don’t know which routes I should test. I must work me trough this config.

Also I have switch of my default network of the VM ( which you can see in brctl show, named virbr0) for testing, with the command: virsh net-destroy default. Just for working only with my bridge environment.

b - if the VM is a test for a router: then it needs to be set up properly with IP addresses, forwarding activated, and you’d need a route on the host. And again use a
second VM as the actual target, and avoid having an interface on the host within the same subnet.

I will try it with several routes. The forwarding is activated.

Then I think I try a new Installation, physical and the VM just for testing. My old VM with Snort, I have stored, and I can use this later. Then I can go the way of connection without a detour. Because I know the paces.

I think I understand to little of my system, that there is the address of my old router although I have not set this one. I don’t know how more confused settings are in this installation?

Sorry the netstat output don’t show my complete work with routes. But in the moment I have set it back at work from default.

Thank you,
Flo

9

Hi Flo,

just for future reports - it’d be much easier to read if you would c&p the invocation and output of commands inside a [ CODE ] … [ / CODE ] block (use the “#” action in the web-based forum editor to place the tags around currently selected text) rather than appending PDFs, which not even show how and on which host the statements were executed :slight_smile:

So you’d like to use Snort? AFAIR it is just lurking on the network port, so the machines does not need to be a router - instead you could i.e. set up a mirror port on your switch to catch all traffic at an interesting point in your network. Please note that as you’ll most likely are running a switched network, you may not catch all inter-node traffic inside your LAN, i.e. some worm scanning for other hosts to infect…

Then I think I try a new Installation, physical and the VM just for testing.

To avoid routing problems, try the following setup:

(host - br*) vmnet (vif - vmA - vif) anotherVmnet (vif - vmB)

host is present only on 192.168.2.0, via br (as currently set up), and vmA has to have two virtual interfaces (this actually could be your current Snort VM as currently set up). vmB needs only a single virtual interface and is present on 192.168.178.0 (i.e. via the 192.168.178.38 address), which connects to vmA’s 192.168.178.24 vif via a separate vmnet.

“host” needs to have a route for 192.178.178.0 pointing to 192.168.2.17.
“vmB” needs to have a route for 192.168.2.0 (or a default route) pointing to 192.168.178.24.

Then you should be able to ping 192.168.178.38 from your host, with the following data flow:

  • host will see the route to that network in it’s routing table
  • host will send the ICMP echo request to the IP address 192.168.178.38, from 192.168.2.9, but with vmA’s MAC address (from the 2.1 vif) as destination address
  • vmA will pick up the packet, sees that 192.168.178.0/24 is local, and send the ICMP echo request to vmB via it’s 192.168.178.24 vif
  • vmB receives the request and initiates the response to 192.168.2.9
  • vmB sees the routing entry (default or 192.168.2.0) and accordingly sends the packet to the according router (vmA) - as above, with destination IP 192.168.2.9 but the MAC address of the router’s (192.168.178.24) vif
  • vmAwill pick up the packet, sees that 192.168.2.0/24 is local
  • vmA will send the ICMP echo response to host via it’s 192.168.2.17 vif
  • host will receive the ICMP echo response (via br with the 2.17 address) and “ping” will report the response.

You can follow the data flow by tcpdump’ing the involved interfaces - br* on host, eth0, eth1 on vmA and eth0 on vmB.

FYI: The ICMP packets will retain source and destination IP address while traversing the chain - but the MAC addresses will change, depending on the link (host->vmA and vmA->vmB).

Regards,
Jens

10

Hi Jens,

first, thank you for your much work, this reply consists of. Wow!

Yes! I must format my replys better.

Yes I know this solution with a mirror port. But if I understanding the manuals right, you can run Snort in a „Inline Mode“. The most Important difference is that snort can active drop network packets instead of just read them.

OK! I need time for testing your proceed.

First of all I take a paper and a pen and draw your infrastructure.

I will post the result.

Many Thanks to you,
Flo

11

Hallo Jens,

first of all I have a positiv result: I have a recognized signal in my FORWARD chain.

Second a big sorry!

My net structur should see like the following:

Laptop > Server with VM and Snort > Internet Router.

Just for testing I have work just with my Server. I thought there is no difference.

But with my Server, VM and with the two bridges it’s all the same config.

Third is following. The recognized signal is just if I ping from my Laptop to my host (br0), but with no answer. I don’t see the normal activity of ping in my Terminal. There is nothing happend but the signal is recognized.

OH! after more times like above I see a ping output. But the output is:

But if I ping from my host (br0) to my Laptop it isn’t work.

There is the output of ping:

this time without a intermediate step about the VM.

This result works with a normal ping from IP to IP – address. But I don’t know how I can use a mac address as the destination address like you tell me? Is this a normally way for a system which is networking, because the output of above ping tells me about:

is this the thing you wrote and mean in in your description ( with the mac-address)?

Curious! : In my host and in my VM the result of the command

was [QUOTE]192.168.2.1[/QUOTE]

my old, but in the moment not setting, internet router. First I have set my gateway to 0.0.0.0, in the host and the VM.

I can just write in the SUSE Forum until Friday the 6.8. Not until then at Monday the 10.8.

Thank you,
Flo

12

Hi Flo,

just a few notes, to push you in the right direction:

From 192.168.178.24 icmp-seq=XX Destination Host Unreachable

So you called ping on machineA (pinging “destination IP”), and the ICMP echo request was forwarded to 192.168.178.24, which then didn’t know how to forward the packet to the destination IP What you see is the resulting “ICMP dest unreachable” packet from 192.168.178.24, send to the IP of machineA.

Have a look at the host 192.168.178.24 - does it know how to reach “destination IP” (can you ping that IP from 178.24?) and if so, is IP forwarding activated on that machine?

But I don’t know how I can use a mac address as the destination address like you tell me?

You don’t do that - the hosts will do that for you. I was telling you this because when looking at tcpdump traces, you will notice that src & dest IP address of the packets are always the same, but the MAC addresses (link layer) will change.

“Follow the white rabbit.” Mentally trace the ICMP packet and have a look at each host it traverses - how does each host know where to send the packet (it either has to have an interface on the same network, or needs to have a route for the destination IP).

Regards,
Jens

13

Hi Jens,

thanks for: it’s work!

So, I describe the config:

In my Laptop I have the routes:

In my virtual machine I have the routes:

In my host I have the route:

Thank you very much!!

Flo