:strip_exif()/i/2007381076.png?f=thumbmini)
:strip_icc():strip_exif()/u/122040/crop5b1e4d0886e95_cropped.jpeg?f=community)
Opgelost, zie de edits in deze en deze posts
Vanaf mijn LAN, dat geNAT wordt naar het "default" WAN-adres, kan ik geen hosts bereiken op een VLAN op dezelfde router met publieke IP's. Echter, als ik dit probeer zie ik wel TCP SYN richting de betreffende VLAN-hosts gaan én SYN-ACK teruggestuurd worden op de VLAN-interface, maar het komt niet door de pfSense router/firewall heen terug naar de LAN-machine. Van buitenaf zijn de publieke adressen normaal te bereiken, voor zover de firewall openstaat voor specifieke poorten.
Setup
Huidige setup, adressen zijn zoals ze op de interface staan. Niet-relevante delen heb ik weggehaald.
(dit is overigens een flink afwijkende setup t.o.v. die van bijvoorbeeld Kragt-ICT. Ik zit dan ook niet te wachten op antwoorden met "heb je deze setup al geprobeerd?", want ik wil geen setup waar publiek routeerbare adressen achter NAT zitten
)
Ik heb 1 ISP die over ethernet levert (igb0/"WAN", DHCP). Daarover heb ik meerdere tunnels draaien. Twee daarvan zijn voor ExtraIP (gre0, gif1), één is voor Hurricane Electric (gif0). Mijn LAN-traffic (10.33.8.0/24) krijgt uitgaand NAT op het adres van igb0: 213.124.174.x, en de "Outbound NAT mode" op pfSense staat op 'Manual Outbound NAT'.
Ik heb een VM-hypervisor, Debian 10, KVM+QEMU, met 1 NIC op layer 2 verbonden met igb1 (kabel vanaf de machine naar een domme Netgear-switch naar de router). Deze NIC heeft geen IP-adressen ingesteld, maar wel een tagged VLAN-interface, met 185.216.161.234/29 als adres. Op deze hypervisor draait (op een losse bridge) een VM met adres 185.216.161.237/32, en een host-route naar 185.216.161.233 (config verderop). De firewall op de VM-hypervisor laat verkeer van/naar de VM's ongefilterd toe.
Ik heb een laptop, Arch Linux, met 1 NIC op layer 2 verbonden met igb1 en adres 10.33.8.12/24.
Tests
Ping vanaf een externe machine:
Ping vanaf mijn laptop:
Zet ik op mijn router een tcpdump open op de VLAN-interface, igb1.1337:
... dan zie je dat beide ICMP requests de betreffende machine bereiken, er een reply komt voor beide requests. De reply die naar 't WAN-ip wordt gestuurd komt echter niet terug op de laptop.
pfTop laat, tijdens het pingen vanaf de LAN-host het volgende zien (mocht iemand weten hoe je de interface-namen er ook bij krijgt, graag!):
/f/image/K3jCkcyxZV9TCYtqbH4dDMlF.png?f=fotoalbum_large)
Diagnose
Waarschijnlijk mist pfSense iets om (in dit geval ICMP) correct terug te vertalen richting de geNAT-e laptop. Ik zou verwachten dat met de (enige) Outbound NAT-regel dit correct wordt terugvertaald... of dat een pass-firewall-regel op EXTRAIPVLAN benodigd is. Dat laatste heb ik ook onderzocht, door de default drop-regels ook te loggen, maar bij de terugkomende packets wordt geen drop hiervoor vermeld.
Ik ben benieuwd of jullie nog verhelderende inzichten hebben.
Vanaf mijn LAN, dat geNAT wordt naar het "default" WAN-adres, kan ik geen hosts bereiken op een VLAN op dezelfde router met publieke IP's. Echter, als ik dit probeer zie ik wel TCP SYN richting de betreffende VLAN-hosts gaan én SYN-ACK teruggestuurd worden op de VLAN-interface, maar het komt niet door de pfSense router/firewall heen terug naar de LAN-machine. Van buitenaf zijn de publieke adressen normaal te bereiken, voor zover de firewall openstaat voor specifieke poorten.
Setup
Huidige setup, adressen zijn zoals ze op de interface staan. Niet-relevante delen heb ik weggehaald.
code:
1
2
3
4
5
6
7
8
| router: pfSense 2.4.5-RELEASE-p1 op PCengines apu2e4, 3 fysieke poorten (2 in gebruik)
igb0: 213.124.174.x/25 "WAN" (wan)
`--- gif0: 2001:470:1f14:x "HENETv6" (opt1)
`--- gre0: 5.255.x.x/30 "EXTRAIPV4" (opt2)
`--- gif1: 2a03:10c3:10:x "EXTRAIPV6" (opt4)
igb1: 10.33.8.1/24 "LAN" (lan)
`--- igb1.1337: 185.216.161.233/29 "EXTRAIPVLAN" (opt3) |
(dit is overigens een flink afwijkende setup t.o.v. die van bijvoorbeeld Kragt-ICT. Ik zit dan ook niet te wachten op antwoorden met "heb je deze setup al geprobeerd?", want ik wil geen setup waar publiek routeerbare adressen achter NAT zitten
)Ik heb 1 ISP die over ethernet levert (igb0/"WAN", DHCP). Daarover heb ik meerdere tunnels draaien. Twee daarvan zijn voor ExtraIP (gre0, gif1), één is voor Hurricane Electric (gif0). Mijn LAN-traffic (10.33.8.0/24) krijgt uitgaand NAT op het adres van igb0: 213.124.174.x, en de "Outbound NAT mode" op pfSense staat op 'Manual Outbound NAT'.
Ik heb een VM-hypervisor, Debian 10, KVM+QEMU, met 1 NIC op layer 2 verbonden met igb1 (kabel vanaf de machine naar een domme Netgear-switch naar de router). Deze NIC heeft geen IP-adressen ingesteld, maar wel een tagged VLAN-interface, met 185.216.161.234/29 als adres. Op deze hypervisor draait (op een losse bridge) een VM met adres 185.216.161.237/32, en een host-route naar 185.216.161.233 (config verderop). De firewall op de VM-hypervisor laat verkeer van/naar de VM's ongefilterd toe.
Ik heb een laptop, Arch Linux, met 1 NIC op layer 2 verbonden met igb1 en adres 10.33.8.12/24.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| VM-hypervisor:
# ip a
2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 44:37:e6:45:e2:d9 brd ff:ff:ff:ff:ff:ff
5: extraip@nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:23:42:aa:aa:aa brd ff:ff:ff:ff:ff:ff
inet 185.216.161.234/29 brd 185.216.161.239 scope global extraip
valid_lft forever preferred_lft forever
inet6 2a03:10c3:x/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::223:42ff:feaa:aaaa/64 scope link
valid_lft forever preferred_lft forever
# ip r
default via 185.216.161.233 dev extraip proto static
185.216.161.232/29 dev extraip proto kernel scope link src 185.216.161.234
185.216.161.235 dev virbr-stoel proto static scope link
185.216.161.237 dev virbr-klant proto static scope link
VM:
# ip a
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:c9:e6:71 brd ff:ff:ff:ff:ff:ff
inet 185.216.161.237/32 scope global enp1s0
valid_lft forever preferred_lft forever
# ip r
default via 185.216.161.233 dev enp1s0 onlink |
Tests
Ping vanaf een externe machine:
code:
1
2
3
4
5
6
7
8
9
10
| $ ip route get 185.216.161.237
185.216.161.237 via 116.202.83.56 dev enp1s0 src 178.63.116.169 uid 1000
cache
$ ping -c1 185.216.161.237
PING 185.216.161.237 (185.216.161.237) 56(84) bytes of data.
64 bytes from 185.216.161.237: icmp_seq=1 ttl=56 time=20.2 ms
--- 185.216.161.237 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.154/20.154/20.154/0.000 ms |
Ping vanaf mijn laptop:
code:
1
2
3
4
5
6
7
8
| $ ip route get 185.216.161.237
185.216.161.237 via 10.33.8.1 dev enp0s25 src 10.33.8.12 uid 1000
cache
$ ping -c1 185.216.161.237
PING 185.216.161.237 (185.216.161.237) 56(84) bytes of data.
--- 185.216.161.237 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms |
Zet ik op mijn router een tcpdump open op de VLAN-interface, igb1.1337:
code:
1
2
3
4
5
6
7
8
| : tcpdump -eni igb1.1337 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb1.1337, link-type EN10MB (Ethernet), capture size 262144 bytes 18:46:34.869081 00:0d:b9:56:ad:fd > 00:23:42:aa:aa:aa, ethertype IPv4 (0x0800), length 98: 178.63.116.169 > 185.216.161.237: ICMP echo request, id 4864, seq 1, length 64 18:46:34.869575 00:23:42:aa:aa:aa > 00:0d:b9:56:ad:fd, ethertype IPv4 (0x0800), length 98: 185.216.161.237 > 178.63.116.169: ICMP echo reply, id 4864, seq 1, length 64 18:46:39.640046 00:0d:b9:56:ad:fd > 00:23:42:aa:aa:aa, ethertype IPv4 (0x0800), length 98: 213.124.174.x > 185.216.161.237: ICMP echo request, id 38853, seq 1, length 64 18:46:39.640481 00:23:42:aa:aa:aa > 00:0d:b9:56:ad:fd, ethertype IPv4 (0x0800), length 98: 185.216.161.237 > 213.124.174.x: ICMP echo reply, id 38853, seq 1, length 64 |
... dan zie je dat beide ICMP requests de betreffende machine bereiken, er een reply komt voor beide requests. De reply die naar 't WAN-ip wordt gestuurd komt echter niet terug op de laptop.
pfTop laat, tijdens het pingen vanaf de LAN-host het volgende zien (mocht iemand weten hoe je de interface-namen er ook bij krijgt, graag!):
:fill(white):strip_exif()/f/image/K3jCkcyxZV9TCYtqbH4dDMlF.png?f=user_large)
Diagnose
Waarschijnlijk mist pfSense iets om (in dit geval ICMP) correct terug te vertalen richting de geNAT-e laptop. Ik zou verwachten dat met de (enige) Outbound NAT-regel dit correct wordt terugvertaald... of dat een pass-firewall-regel op EXTRAIPVLAN benodigd is. Dat laatste heb ik ook onderzocht, door de default drop-regels ook te loggen, maar bij de terugkomende packets wordt geen drop hiervoor vermeld.
Ik ben benieuwd of jullie nog verhelderende inzichten hebben.
:fill(white):strip_exif()/f/image/1cl6MjJw97wl5Mm690EpH13m.png?f=user_large)
.