• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

bhyve und packet filter

MarcoHensel

Well-Known Member
Themenstarter #1
Hallo liebe Gemeinde,


ich plane einen HV mit bhyve bei Hetzner zu betreiben. Bisher sieht alles wunderbar aus, wenn letztendlich noch ein Problem mit 'pf` behoben werden kann.


Aus Gruenden die sich mir derzeit nicht genauer erschliessen werden die von einer bhyve-client Instanz ausgehenden Packete von pf gedropt, obwohl eine pass rule (kein quick vorher) existiert.
Eigentlich sind es nicht die direkt die ausgehenden, sondern die syn-ack die als Antwort zurueck kommen sollen.

Hier der Aufbau:
Code:
ext_if  (public IP [ZZZ]) -> "router" (bhyvevm) pub_if (zweite public IP [YYY, GWZ]), int_if ( sub_net/29 [XXX]) -> "client-vm" (fbsd12_64) int_if (public  [AAA/32, GWX])
Synonyme:
Code:
public IP:             ZZZ
2nd public IP:         YYY
int. router IP:        XXX
VM-IP aus sub_net/29:  AAA
externer GW:           GWZ
interner GW:           GWX
internet client:       ANY
-------------------------
was funktioniert:
cmd ANY> ping AAA
Code:
10:16:31.992733 IP ANY > AAA: ICMP echo request, id 54608, seq 4, length 40
10:16:31.992823 IP AAA > ANY: ICMP echo reply, id 54608, seq 4, length 40

cmd ANY> curl AAA:80
Code:
10:18:09.497117 IP ANY.10167 > AAA.80: Flags [S], seq 522195871, win 65535, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
10:18:09.497199 IP AAA.80    > ANY.10167: Flags [S.], seq 2009854360, ack 522195872, win 65535, options [mss 1460,nop,wscale 6,sackOK,eol], length 0
10:18:09.523287 IP ANY.10167 > AAA.80: Flags [.], ack 1, win 16383, length 0
10:18:09.523985 IP ANY.10167 > AAA.80: Flags [P.], seq 1:113, ack 1, win 16383, length 112: HTTP: GET / HTTP/1.1
10:18:09.524461 IP AAA.80    > ANY.10167: Flags [P.], seq 1:330, ack 113, win 1026, length 329: HTTP: HTTP/1.1 200 OK
10:18:09.559133 IP ANY.10167 > AAA.80: Flags [F.], seq 113, ack 330, win 16301, length 0
10:18:09.559243 IP AAA.80    > ANY.10167: Flags [.], ack 114, win 1026, length 0
10:18:09.559339 IP AAA.80    > ANY.10167: Flags [F.], seq 330, ack 114, win 1026, length 0
10:18:09.585219 IP ANY.10167 > AAA.80: Flags [.], ack 331, win 16301, length 0

cmd AAA> ping heise.de
Code:
10:21:42.954534 IP AAA           > 193.99.144.80: ICMP echo request, id 36360, seq 13, length 64
10:21:42.984693 IP 193.99.144.80 > AAA: ICMP echo reply, id 36360, seq 13, length 64

-------------------------
was NICHT funktioniert:
cmd AAA> curl heise.de
(no reply)

cmd ZZZ> tcpdump -i ext_if -n host 193.99.144.80
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ext_if, link-type EN10MB (Ethernet), capture size 262144 bytes
10:42:10.868726 IP AAA.14212        > 193.99.144.80.80: Flags [S], seq 1514503710, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 10693665 ecr 0], length 0
10:42:10.898605 IP 193.99.144.80.80 > AAA.14212: Flags [S.], seq 439508862, ack 1514503711, win 4380, options [mss 1460,nop,nop,TS val 2983802439 ecr 10693665,sackOK,eol], length 0
10:42:13.898302 IP 193.99.144.80.80 > AAA.14212: Flags [S.], seq 439508862, ack 1514503711, win 4380, options [mss 1460,nop,nop,TS val 2983805439 ecr 10693665,sackOK,eol], length 0
10:42:13.907480 IP AAA.14212        > 193.99.144.80.80: Flags [S], seq 1514503710, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 10696704 ecr 0], length 0
10:42:17.197188 IP AAA.14212        > 193.99.144.80.80: Flags [S], seq 1514503710, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 10699994 ecr 0], length 0

pflog ZZZ>
Code:
 00:00:01.549791 rule 3/0(match): block in on ext_if: 193.99.144.80.80 > AAA.24022: Flags [S.], seq 778016961, ack 142615496, win 4380, options [mss 1460,nop,nop,TS val 2983931327 ecr 10822553,sackOK,eol], length 0
00:00:02.860173 rule 3/0(match): block in on ext_if: 193.99.144.80.80 > AAA.24022: Flags [S.], seq 778016961, ack 142615496, win 4380, options [mss 1460,nop,nop,TS val 2983934327 ecr 10822553,sackOK,eol], length 0
00:00:01.069542 rule 3/0(match): block in on ext_if: 193.99.144.80.80 > AAA.24022: Flags [S.], seq 778016961, ack 142615496, win 4380, options [mss 1460,nop,nop,TS val 2983940327 ecr 10822553,sackOK,eol], length 0

cmd ZZZ> pfctl -vnf /etc/pf.conf (gekuerzt)
Code:
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
set fingerprints "/etc/pf.os"
scrub in all fragment reassemble
table <__automatic_0> const { 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 0.0.0.0/8 240.0.0.0/4 }
table <__automatic_1> const { 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 0.0.0.0/8 240.0.0.0/4 }
table <__automatic_2> const { 194.150.168.168 208.67.222.222 208.67.220.220 208.67.222.220 208.67.220.222 204.152.184.76 213.73.91.35 80.237.196.2 194.95.202.198 212.114.152.1 212.114.153.1 213.133.98.98 213.133.99.99 213.133.100.100 }
block drop in quick on exit_if inet from <__automatic_0> to any
block drop out quick on exit_if inet from any to <__automatic_1>
block drop in log quick from urpf-failed to any
block drop in log all
pass out all flags S/SA keep state
pass quick on lo0 all flags S/SA keep state
block drop in log quick on ! exit_if inet from YYY/26 to any
block drop in log quick inet from ZZZ to any
pass in on exit_if inet proto udp from <__automatic_2> to ZZZ port = domain keep state
pass in on exit_if inet proto tcp from any to ZZZ port = 22 flags S/SA keep state
pass in on exit_if inet proto icmp from <__automatic_3> to ZZZ keep state
pass in on exit_if inet proto tcp from any to AAA/29 flags S/SA keep state
pass in on exit_if inet proto udp from any to AAA/29 keep state
pass in on exit_if inet proto icmp from any to AAA/29 keep state
pass in on exit_if inet from YYY/26 to any flags S/SA keep state

Wenn die Rule "block drop in log all" auf dem HV/ext_if/ZZZ auskommentiert oder 'pfctl -d' ausfuehrt wird funktioniert alles. Ich moechte aber 'pf' nicht deaktiviert lassen, hat jemand eine Idee ?


Viele Gruesse,

Marco
 

medV2

Well-Known Member
#2
Ich versteh dein Setup noch nicht ganz. Du hast 2 Pub IPs, aber keine Weiterleitung oder Nat so auf dem Host konfiguriert. Hast du für das ganze Netz ein Gateway bei Hetzner eingetragen und du routest selbst?
 

MarcoHensel

Well-Known Member
Themenstarter #3
Hallo,

das ist eigentlich ganz simple geloest:

HV:
defaultrouter="GWZ"
ifconfig_ext_if="inet ZZZ netmask 0xffffffc0"
net.inet.ip.forwarding: 1
static_route AAA/29 YYY ## --> AAA/29 YYY UGS ext_if
ifconfig_bridge0="ext_if tap0"
-----
/etc/sysctl.conf
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
net.link.bridge.pfil_member=0
net.link.bridge.pfil_onlyip=1
net.link.tap.up_on_open=1
net.link.tap.user_open=1



Router VM:
net.inet.ip.forwarding: 1
ifconfig_vtnet0="inet YYY netmask 255.255.255.192"
ifconfig_vtnet1="inet GWX netmask 255.255.255.248"
defaultrouter="GWZ"


Client VM:
ifconfig_vtnet0="inet AAA netmask 255.255.255.248"
defaultrouter="GWX"


keine weiteren Einstellungen. Moeglicherweise mach ich auch konzeptionell etwas verkehrt. Bisher bin ich von Virtualbox gewoehnt, ein Interface mit dem ext_if zu bridge'n und die routen finden sich. Auf dem alten Cluster hab ich noch nichtmal ein forwarding aktiv.

Wie schon erwaehnt, eigentlich b(l)ockt nur pf aktuell.

Gruesse,
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#4
defaultrouter="GWZ"
ifconfig_ext_if="inet ZZZ netmask 0xffffffc0"
net.inet.ip.forwarding: 1
static_route AAA/29 YYY ## --> AAA/29 YYY UGS ext_if
ifconfig_bridge0="ext_if tap0"
Das kann nicht gehen, bzw. wird seltsame Fehler verursachen. Adressen müssen immer auf der Bridge liegen, niemals auf ihren Membern. Denn FreeBSD verarbeitet Pakete immer auf dem letzten Interface, eingehend also auf der Bridge, ausgehend auf ext_if. Damit ist bei dir das eingehende Interface ungleich dem ausgehenden Interface, was FreeBSD Netzwerkstack, aber auch Switches und andere Stationen im Netz wunderbar verwirrt.

Außerdem würde ich empfehlen, der Bridge noch händisch eine MAC-Adresse zu setzen. Denn die zufällig generierten Adressen sind nur auf einer Maschine garantiert eindeutig. Ich hatte schon MAC-Kollisionen zwischen Bridges auf verschiedenen Maschinen und es war nicht schön. Alleine, da erstmal drauf zu kommen...