Tagged VLAN's host/ bridged VM en ping probleempje

[johan2009]

Ik zit met een mysterie waar ik niet uitkom. Post op Ubuntu-forum en Netgate-forum (pfSense) levert geen antwoord op die mij helpt. host met VLAN-interface geeft geen ICMP-reply van ander subnet. Als volgt;

Focus ligt in deze vraag vooral bij host Htpc in diagram;


Nu krijg ik het niet voor elkaar om host te pingen waarop 3 getagde VLAN's zijn geconfigureerd. .Vlan 130 is wel pingbaar is vanuit andere subnets, 132 is voor IOT-stuff en 133 wordt DMZ. Laatste 2 vlan's dus geen reply. Vlan-iot-interface (ID 132) alleen in zelfde subnet.

Alle hosts zijn voor DHCP geconfigureerd. Alleen VM Guest (Debian VM), die in Virtualbox middels bridged network aan host Htpc op vlan-dmz (ID: 133) is gekoppeld, geeft replies. Host zelf niet.

TCPdump listening on BRIDGEDIOT-interface pfSense. Ping from host LAN-subnet And from host WLANGUEST to host Htpc IOT-subnet;

18:19:17.612968 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 28, length 64
18:19:18.405515 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 19, length 64
18:19:18.614008 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 29, length 64
18:19:19.411016 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 20, length 64
18:19:19.614242 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 30, length 64
18:19:20.416574 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 21, length 64
18:19:20.616907 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 31, length 64
18:19:21.053445 IP 192.168.132.133.42102 > 239.255.255.250.1900: UDP, length 126
18:19:21.421993 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 22, length 64
18:19:21.620510 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 32, length 64
18:19:22.427412 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 23, length 64
18:19:22.553453 IP 192.168.132.133.57621 > 192.168.132.255.57621: UDP, length 44
18:19:22.622639 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 33, length 64
18:19:23.432543 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 24, length 64
18:19:23.624955 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 34, length 64
18:19:23.819926 IP 192.168.132.133.48448 > 192.168.132.129.53: UDP, length 48
18:19:23.870237 IP 192.168.132.129.53 > 192.168.132.133.48448: UDP, length 88
18:19:24.436550 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 25, length 64
18:19:24.627276 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 35, length 64
18:19:25.442658 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 26, length 64
18:19:25.628934 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 36, length 64
18:19:26.447828 IP 192.168.131.131 > 192.168.132.133: ICMP echo request, id 0, seq 27, length 64
18:19:26.630960 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 61189, seq 37, length 64

TCPdump on host 'htpc' IOT-subnet on vlan-iot

raymond@htpc:~$ sudo tcpdump -i vlan-iot
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan-iot, link-type EN10MB (Ethernet), capture size 262144 bytes
18:22:22.579128 IP htpc.57621 > 192.168.132.255.57621: UDP, length 44
18:22:22.582521 IP htpc.35299 > _gateway.domain: 4793+ [1au] PTR? 255.132.168.192.in-addr.arpa. (57)
18:22:22.582914 IP _gateway.domain > htpc.35299: 4793 NXDomain* 0/1/1 (116)
18:22:22.583162 IP htpc.35299 > _gateway.domain: 4793+ PTR? 255.132.168.192.in-addr.arpa. (46)
18:22:22.583536 IP _gateway.domain > htpc.35299: 4793 NXDomain* 0/1/0 (105)
18:22:22.585752 IP htpc.40124 > _gateway.domain: 37925+ [1au] PTR? 129.132.168.192.in-addr.arpa. (57)
18:22:22.586184 IP _gateway.domain > htpc.40124: 37925 NXDomain* 0/1/1 (116)
18:22:22.586278 IP htpc.40124 > _gateway.domain: 37925+ PTR? 129.132.168.192.in-addr.arpa. (46)
18:22:27.704279 ARP, Request who-has _gateway tell htpc, length 28
18:22:27.704484 ARP, Reply _gateway is-at 02:0f:c1:d7:81:01 (oui Unknown), length 46
18:22:47.552069 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 409
18:22:47.552086 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 481
18:22:47.552090 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:22:47.552093 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 477
18:22:47.552140 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:22:47.552146 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 457
18:22:47.552149 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:22:52.579511 IP htpc.57621 > 192.168.132.255.57621: UDP, length 44
18:23:17.578857 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 409
18:23:17.578939 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 481
18:23:17.578944 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:23:17.578947 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 477
18:23:21.050920 IP htpc.42102 > 239.255.255.250.1900: UDP, length 126
18:23:22.580104 IP htpc.57621 > 192.168.132.255.57621: UDP, length 44
18:23:47.591834 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 409
18:23:47.591851 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 481
18:23:47.859711 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:23:47.859713 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 457
18:23:47.859715 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:23:47.859782 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:23:47.859787 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 409
18:23:52.580636 IP htpc.57621 > 192.168.132.255.57621: UDP, length 44
18:24:08.523712 IP htpc.60768 > 239.255.255.250.1900: UDP, length 172
18:24:09.524293 IP htpc.60768 > 239.255.255.250.1900: UDP, length 172
18:24:10.524833 IP htpc.60768 > 239.255.255.250.1900: UDP, length 172
18:24:11.525775 IP htpc.60768 > 239.255.255.250.1900: UDP, length 172
18:24:14.648905 IP htpc.50796 > 23-111-157-86.static.hvvc.us.4000: UDP, length 24
18:24:14.649509 IP htpc.36129 > _gateway.domain: 41992+ [1au] PTR? 86.157.111.23.in-addr.arpa. (55)
18:24:14.759058 IP 23-111-157-86.static.hvvc.us.4000 > htpc.50796: UDP, length 20
18:24:15.745194 IP _gateway.domain > htpc.36129: 41992 1/0/1 PTR 23-111-157-86.static.hvvc.us. (97)
18:24:15.745231 IP htpc > _gateway: ICMP htpc udp port 36129 unreachable, length 133
18:24:17.045432 IP htpc.50796 > 66-165-233-194.static.hvvc.us.4000: UDP, length 24
18:24:17.045954 IP htpc.39556 > _gateway.domain: 304+ [1au] PTR? 194.233.165.66.in-addr.arpa. (56)
18:24:17.214250 IP 66-165-233-194.static.hvvc.us.4000 > htpc.50796: UDP, length 20
18:24:17.640458 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 409
18:24:17.640557 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 481
18:24:17.640564 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:24:17.907664 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:24:17.907666 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 457
18:24:17.907668 IP _gateway.39402 > 239.255.255.250.1900: UDP, length 417
18:24:17.926893 IP _gateway.domain > htpc.39556: 304 1/0/1 PTR 66-165-233-194.static.hvvc.us. (99)
18:24:17.926929 IP htpc > _gateway: ICMP htpc udp port 39556 unreachable, length 135
18:24:19.832258 ARP, Request who-has _gateway tell htpc, length 28
18:24:19.832475 ARP, Reply _gateway is-at 02:0f:c1:d7:81:01 (oui Unknown), length 46
18:24:22.581881 IP htpc.57621 > 192.168.132.255.57621: UDP, length 44

TCPdump listening on BRIDGEDIOT-interface pfSense. Ping from host LAN-subnet (192.168.130.135) to host IOT-subnet And from host htpc (192.168.132.133) IOT-subnet;

20:49:53.179907 LLDP, length 242: switch
20:49:53.249628 IP 192.168.132.133.57621 > 192.168.132.255.57621: UDP, length 44
20:49:53.275987 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 21, length 64
20:49:54.279214 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 22, length 64
20:49:55.280684 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 23, length 64
20:49:56.282219 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 24, length 64
20:49:57.284520 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 25, length 64
20:49:58.285231 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 26, length 64
20:49:59.288202 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 27, length 64
20:50:00.289155 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 28, length 64
20:50:01.291632 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 29, length 64
20:50:02.293119 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 30, length 64
20:50:03.297943 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 31, length 64
20:50:04.298194 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 32, length 64
20:50:05.298473 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 33, length 64
20:50:06.299761 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 34, length 64
20:50:07.302180 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 35, length 64
20:50:08.307137 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 36, length 64
20:50:08.617221 IP 192.168.132.133.33796 > 239.255.255.250.1900: UDP, length 172
20:50:09.307815 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 37, length 64
20:50:09.617899 IP 192.168.132.133.33796 > 239.255.255.250.1900: UDP, length 172
20:50:10.308168 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 38, length 64
20:50:10.618888 IP 192.168.132.133.33796 > 239.255.255.250.1900: UDP, length 172
20:50:12.436720 IP 192.168.132.133.50046 > 192.168.132.129.53: UDP, length 34
20:50:12.436933 IP 192.168.132.133.36811 > 192.168.132.129.53: UDP, length 34
20:50:12.476695 IP 192.168.132.129.53 > 192.168.132.133.50046: UDP, length 98
20:50:12.476856 IP 192.168.132.133 > 192.168.132.129: ICMP 192.168.132.133 udp port 50046 unreachable, length 134
20:50:12.478372 IP 192.168.132.129.53 > 192.168.132.133.36811: UDP, length 34
20:50:12.478568 IP 192.168.132.133 > 192.168.132.129: ICMP 192.168.132.133 udp port 36811 unreachable, length 70
20:50:13.310931 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 41, length 64
20:50:14.315405 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 42, length 64
20:50:15.319584 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 43, length 64
20:50:16.323632 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 44, length 64
20:50:17.325918 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 45, length 64
20:50:17.596892 ARP, Request who-has 192.168.132.129 tell 192.168.132.133, length 46
20:50:17.596921 ARP, Reply 192.168.132.129 is-at 02:0f:c1:d7:81:01, length 28
20:50:18.326224 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 46, length 64
20:50:19.329571 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 47, length 64
20:50:19.439597 IP 192.168.132.133.59647 > 192.168.132.129.53: UDP, length 34
20:50:19.439833 IP 192.168.132.133.42127 > 192.168.132.129.53: UDP, length 34
20:50:19.439937 IP 192.168.132.129.53 > 192.168.132.133.59647: UDP, length 98
20:50:19.440136 IP 192.168.132.133 > 192.168.132.129: ICMP 192.168.132.133 udp port 59647 unreachable, length 134
20:50:19.468550 IP 192.168.132.129.53 > 192.168.132.133.42127: UDP, length 34
20:50:19.499906 IP 192.168.132.133.57149 > 192.168.132.129.53: UDP, length 54
20:50:20.053295 IP 192.168.132.129.53 > 192.168.132.133.57149: UDP, length 109
20:50:20.053495 IP 192.168.132.133 > 192.168.132.129: ICMP 192.168.132.133 udp port 57149 unreachable, length 145
20:50:20.334721 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 48, length 64
20:50:21.339863 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 49, length 64
20:50:22.342437 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 50, length 64
20:50:23.250412 IP 192.168.132.133.57621 > 192.168.132.255.57621: UDP, length 44
20:50:23.345154 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 51, length 64
20:50:23.820895 LLDP, length 242: switch
20:50:24.349488 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 52, length 64
20:50:25.351755 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 53, length 64
20:50:26.352909 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 54, length 64
20:50:27.314823 IP 192.168.132.133.53560 > 192.168.132.129.53: UDP, length 34
20:50:27.315063 IP 192.168.132.133.38566 > 192.168.132.129.53: UDP, length 34
20:50:27.315164 IP 192.168.132.129.53 > 192.168.132.133.53560: UDP, length 98
20:50:27.315392 IP 192.168.132.133 > 192.168.132.129: ICMP 192.168.132.133 udp port 53560 unreachable, length 134
20:50:27.342517 IP 192.168.132.129.53 > 192.168.132.133.38566: UDP, length 34
20:50:27.356815 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 55, length 64
20:50:28.358641 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 56, length 64
20:50:29.358716 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 57, length 64
20:50:30.358828 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 28422, seq 58, length 64

Vandaag kreeg ik een ingeving; ik dacht laat ik eens een backup VM Guest met host bridgen op vlan-iot (waarvan host dus geen replies geeft vanuit andere subnets). Wat denk je. VM guest is pingbaar en kan deze werkzaam als webserver vanuit andere subnets benaderen.

Volgens mij kan je in tcpdumps zien dat host Htpc “not reachable” op udp poort is voor interface op pfSense. Ik snap er niets van. Er is geen firewall geconfigureerd. Hoe kan dit?

[ Voor 9% gewijzigd door johan2009 op 30-11-2019 13:35 . Reden: Ingekort; hopelijk eerder reactie ]

[johan2009]

Deze vraag moet te doen zijn voor jullie networking guys. Toch?

[DukeBox]

Hoe staan de maskers ?

[Vorkie]

Heb je onderstaande ook eens over nagedacht?

Jij stuurt ping van netwerk VLAN130 via PFSense naar VLAN132 zonder NAT translatie.

Verkeer komt op de htpc binnen met 192.168.130.x, deze matched met de interface in VLAN130 op de htpc waar je terecht komt en probeert hem zo weer terug te sturen via die interface.

[johan2009]

DukeBox schreef op zaterdag 30 november 2019 @ 17:56:
Hoe staan de maskers ?

Ze staan me goed dank je wel! Bedoel je subnetmask? Zie afbeelding.

[johan2009]

Vorkie schreef op zaterdag 30 november 2019 @ 18:01:
Heb je onderstaande ook eens over nagedacht?

Jij stuurt ping van netwerk VLAN130 via PFSense naar VLAN132 zonder NAT translatie.

Verkeer komt op de htpc binnen met 192.168.130.x, deze matched met de interface in VLAN130 op de htpc waar je terecht komt en probeert hem zo weer terug te sturen via die interface.

Private subnets hoeven niet te NAT'ten toch? Haal je dit uit de dumps? Zo ja hoe en waar zie je dat? Namelijk handig om hiervan te leren.

EDIT: Als ik van VLAN130 via pfSense naar VLAN132 ping, waarom zou het dan op Htpc op 192.168.130.133 (VLAN130) binnenkomen? Een gebridge VM Guest op desbetreffende host Htpc werkt zoals het moet.

[ Voor 14% gewijzigd door johan2009 op 30-11-2019 18:24 ]

[Vorkie]

johan2009 schreef op zaterdag 30 november 2019 @ 18:18:
[...]


Private subnets hoeven niet te NAT'ten toch? Haal je dit uit de dumps? Zo ja hoe en waar zie je dat? Namelijk handig om hiervan te leren.

Nee die hoef je niet te NATten, maar gezien je nu het device ook direct in het VLAN hebt staan is dat wel routeringtechnisch handig, het subnet is namelijk ook bekend in de lokale route tabel van de HTPC, elk IP adres uit 1 van die interfaces verwacht ie op die interface en niet op een andere.

Ik zou eerder alles maar 1 VLAN aanhouden en dan via PFSense de firewalling regelen tussen de VLAN's of heb je een reden dat sommige apparaten meerdere interfaces moeten hebben?

/edit

EDIT: Als ik van VLAN130 via pfSense naar VLAN132 ping, waarom zou het dan op Htpc op 192.168.130.133 (VLAN130) binnenkomen? Een gebridge VM Guest op desbetreffende host Htpc werkt zoals het moet.

De bridge VM zit gewoon op VLAN132 en heeft maar 1 interface, die kent de rest van de subnetten geeneens, dus stuurt ie netjes het verkeer weer terug naar de default gateway, PFSense.

[ Voor 21% gewijzigd door Vorkie op 30-11-2019 18:30 ]

[ik222]

Wat @Vorkie zegt klopt maar op zich kan je dan nog steeds pingen, al gaat de ping heen via de firewall en terug rechtstreeks. Asymmetrisch dus.

Ik vermoed dat de host die niet reageert reverse path filtering aan heeft staan. Dat is een mechanisme wat zorgt dat pakketjes waarvan de route terug naar het source ip over een andere interface loopt gedropt worden. In veel Linux kernels staat dat default aan. Je kan het middels sysctl uitzetten (even googlen naar RP filter). Denk dat als je dat uitzet het wel werkt

Maar inderdaad, waarom heeft die host adressen in meerdere subnets? Want security technisch is dit niet optimaal natuurlijk.

[ Voor 12% gewijzigd door ik222 op 30-11-2019 18:38 ]

[Vorkie]

ik222 schreef op zaterdag 30 november 2019 @ 18:37:
Wat @Vorkie zegt klopt maar op zich kan je dan nog steeds pingen, al gaat de ping heen via de firewall en terug rechtstreeks.

Ik vermoed dat de host die niet reageert reverse path filtering aan heeft staan. Dat is een mechanisme wat zorgt dat pakketjes waarvan de route terug naar het source ip over een andere interface loopt gedropt worden. In veel Linux kernels staat dat default aan. Je kan het middels sysctl uitzetten (even googlen naar RP filter). Denk dat als je dat uitzet het wel werkt

stateless natuurlijk, dat andere wist ik niet :-) thx

[johan2009]

@KRGT Ik begrijp het niet. Als ik vanuit een host op VLAN130 ping naar desbetreffende host in VLAN132, ook al is deze ook member van VLAN130, waarom zou deze op interface van VLAN130 reageren? Het valt buiten lokale subnet. Dit verkeer gaat toch anaar de gateway voor host; pfSense interface. Die vervolgens via VLAN132 op host Htpc aankomt en niet VLAN130.

hier dump vanaf Mac in VLAN130;

Raymonds-iMac:~ raymond$ sudo tcpdump -nni en0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:44:27.733276 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 0, length 64
17:44:28.106249 IP 192.168.130.135 > 192.168.130.129: ICMP 192.168.130.135 udp port 57264 unreachable, length 36
17:44:28.733727 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 1, length 64
17:44:29.734319 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 2, length 64
17:44:30.737372 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 3, length 64
17:44:31.737672 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 4, length 64
17:44:32.738150 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 5, length 64
17:44:33.740001 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 6, length 64
17:44:34.743952 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 7, length 64
17:44:35.746334 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 8, length 64
17:44:36.749529 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 9, length 64
17:44:37.750772 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 10, length 64
17:44:38.754603 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 11, length 64
17:44:39.755874 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 12, length 64
17:44:40.757249 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 13, length 64
17:44:41.759586 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 14, length 64
17:44:42.762584 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 15, length 64
17:44:43.767631 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 16, length 64
17:44:44.771744 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 17, length 64
17:44:45.773318 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 18, length 64
17:44:46.773520 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 19, length 64
17:44:47.773716 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 20, length 64
17:44:47.795092 IP 192.168.130.135 > 192.168.130.129: ICMP 192.168.130.135 udp port 63936 unreachable, length 36
17:44:48.775031 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 21, length 64
17:44:49.776786 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 22, length 64
17:44:50.778303 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 23, length 64
17:44:51.781096 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 46596, seq 24, length 64

Als binnen broadcast domain van VLAN130 host Htpc zou aankomen dan zou ik een keer een ARP-request mogen zien... Waar klopt mijn denkwijze niet?

En hoe moet ik deze entry interpreteren; "IP 192.168.130.135 > 192.168.130.129: ICMP 192.168.130.135 udp port 63936 unreachable, length 36"

[Dennisweb]

Beetje offtopic, maar hoe maak je die mooie schematekeningen, @johan2009?

[johan2009]

ik222 schreef op zaterdag 30 november 2019 @ 18:37:
Wat @Vorkie zegt klopt maar op zich kan je dan nog steeds pingen, al gaat de ping heen via de firewall en terug rechtstreeks. Asymmetrisch dus.

Ik vermoed dat de host die niet reageert reverse path filtering aan heeft staan. Dat is een mechanisme wat zorgt dat pakketjes waarvan de route terug naar het source ip over een andere interface loopt gedropt worden. In veel Linux kernels staat dat default aan. Je kan het middels sysctl uitzetten (even googlen naar RP filter). Denk dat als je dat uitzet het wel werkt

Maar inderdaad, waarom heeft die host adressen in meerdere subnets? Want security technisch is dit niet optimaal natuurlijk.

Je hebt gelijk!!! Ik heb op de host "sudo sysctl -w 'net.ipv4.conf.all.rp_filter=0'
net.ipv4.conf.all.rp_filter = 0" gedaan en;

18:16:00.933476 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 0, length 64
18:16:01.936357 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 1, length 64
18:16:02.941516 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 2, length 64
18:16:03.945797 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 3, length 64
18:16:04.949364 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 4, length 64
18:16:05.949592 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 5, length 64
18:16:06.950307 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 6, length 64
18:16:07.954350 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 7, length 64
18:16:08.956948 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 8, length 64
18:16:09.959269 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 9, length 64
18:16:10.962473 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 10, length 64
18:16:11.965769 IP 192.168.130.135 > 192.168.132.133: ICMP echo request, id 64516, seq 11, length 64
18:16:12.713351 IP 192.168.130.135 > 192.168.130.129: ICMP 192.168.130.135 udp port 53147 unreachable, length 36

[johan2009]

Dennisweb schreef op zondag 1 december 2019 @ 17:52:
Beetje offtopic, maar hoe maak je die mooie schematekeningen, @johan2009?

Dat doe ik met Sketch. Zelf ff wat geometrische vormpjes maken. Dit is een design-tool waar ik bekend mee ben. Dat is mijn werk. Deze vraag is hobby en ik er niet tegen kan als ik het niet begrijp/uitkom.

[johan2009]

Trouwens, ik gebruik 1 host met meerdere vlan's omdat op VLAN130 als Htpc/Fileserver fungeert. In de toekomst wil ik al het IOT-spul in VLAN132 geïsoleerd hebben waaronder Home Assistant. Het is handig dat het LAN-subnet wel bij Home Assistant (HA) kan om te configureren etc. Gezien ik HA als docker-container gebridged die op VLAN132 wil zetten, heeft host 2 tagged vlan-interfaces nodig. Ook heb ik VM Guest op deze host op 3de tagged vlan gezet. Enfin als is geschieden alleen host Htpc is zwakste schakel mbt. toegang tot meerdere segementen. Tja dat was dat ikzelf kon bedenken qua beveiliging voor die IOT-meuk.