2 Subnetze via Fritzbox+Router

lockdoc

lockdoc

Well-Known Member
Ich habe hier folgendes Scenario

attachment.php


* Die Fritzbox waehlt sich ins Internet ein und verteilt ueber den Internen DHCP Server die Adressen.
* Alle an der Fritzbox direkt angeschlossenen PC's sind im 192.168.178.0/24 Netz
* Ein FreeBSD Router mit 2 NICS haengt an der Fritzbox und soll ein weiteres Netz aufmachen: 192.168.10.0/24
* In dem Router laeuft eine Jail auf (em0) fuer den DHCP Server, dieser verschickt auch nur DHCP auf dem em0 (192.168.10.20) Alias Interface

Der Router hat folgenden PF Eintrag fuer das NAT, damit die Leute aus dem 192.168.10.0/24 Netz ins Internet kommen sollen.

Code: 
# start of file
ext_if="re0"
int_if="em0"

rede="{192.168.10.0/24}"

nat on $ext_if from $rede to any -> ($ext_if)
#eof


Das Problem ist allerdings, dass alle Clients aus LAN1 (192.168.178.0/24) ploetzlich eine IP von dem Jail DHCP Server erhalten und nicht mehr im eigenen Addressbereich sind.

Zudem koennen alle Clients aus LAN2 (192.168.10.0/24) problemslos die Fritzbox anpingen und darauf zugreifen (obwohl es ein anderes Netz ist).

Nun bin ich ein wenig ratlos und denke ich habe an der pf.conf was falsch gemacht.

Es sollte so sein:
* Subnetze muessen getrennt sein und clients sollen nicht auf das jeweilige andere Zugreifen koennen, da es 2 verschiedene Firmen sind.
* Der FreeBSD Router soll es nur ermoeglichen Internet fuer das LAN2 ueber die Fritzbox herzustellen (und halt dhcp).
* LAN 1 soll gar nicht wissen, das LAN 2 existiert und schoen den DHCP der Fritzbox verwenden.

Jemand eine Idee was ich falsch gemacht habe?
 

Anhänge

  • lan scenario.PNG
    lan scenario.PNG
    24,1 KB · Aufrufe: 2.961
Hi Lockdoc,


hast Du zufällig ein Managebares Switch ?

Falls ja, dann kannst Du die Netzsegmente schön mit vlans trennen.

Ansonsten würd ich wetten das IP forwarding auf der FreeBSD Kiste aktiv ist und die pf den traffic zulässt.

mfg,
 
Die switches sind alles stinknormale Home-switches ohne management, also leider keine VLANs moeglich.

Der FreeBSD Router hat folgende rc.conf
Code: 
hostname="router.internal.int"

# internal
ifconfig_em0="192.168.10.1 netmask 255.255.255.0"

# external
ifconfig_re0="192.168.178.100 netmask 255.255.255.0"
defaultrouter="192.168.178.1"

# -------------- FIREWALL --------------
pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pf.log"

gateway_enable="YES"

# ----- Misc services
sshd_enable="YES"
syslogd_enable="YES"
syslogd_flags="-ss"
noip_enable="YES"

#
# Jail IP Settings
#
ifconfig_em0_alias0="inet 192.168.10.10 netmask 255.255.255.255"   # dns
ifconfig_em0_alias1="inet 192.168.10.11 netmask 255.255.255.255"   # dhcp

ifconfig_lo0_alias0="inet 127.0.10.10 netmask 255.255.255.255"     # dns
ifconfig_lo0_alias1="inet 127.0.10.11 netmask 255.255.255.255"     # dhcp

jail_enable="YES"
jail_set_hostname_allow="NO"
jail_devfs_enable="YES"
jail_mount_enable="YES"
jail_list="dns dhcp"

############### DNS
jail_dns_ip="em0|192.168.10.10,lo0|127.0.10.10"
jail_dns_hostname="dns.internal.int"
jail_dns_rootdir="/var/jails/dns.internal.int"
jail_dns_fstab="/var/jails/fstab.dns"

############### DHCP
jail_dhcp_ip="em0|192.168.10.11,lo0|127.0.10.11"
jail_dhcp_hostname="dhcp.internal.int"
jail_dhcp_rootdir="/var/jails/dhcp.internal.int"
jail_dhcp_fstab="/var/jails/fstab.dhcp"
jail_dhcp_devfs_ruleset="devfsrules_jail_dhcp"

@bofh_hannibal:
Meinst du damit das gateway_enable="YES"?
Ich dachte, dass man das generell braucht, sobald die maschine als router fungiert.
 
lockdoc schrieb:
Die switches sind alles stinknormale Home-switches ohne management, also leider keine VLANs moeglich.
Zum Vergrößern anklicken....

OK, kein macht ja nix. :-)


lockdoc schrieb:
@bofh_hannibal:
Meinst du damit das gateway_enable="YES"?
Ich dachte, dass man das generell braucht, sobald die maschine als router fungiert.
Zum Vergrößern anklicken....

Jepp,
die variable sorgt im /etc/rc.d/routing script dafür das ip forwarding aktiviert wird :-)

Wie schaut denn die PF aus ?


Zum DHCP Problem:

Ist der DHCP in der Jail Authorative ?
Und antwortet der dhcp server auf discover packages ?

mfg
 
Die komplette pf.conf ist im aller ersten Post, mehr steht da nicht drin.

Der DHCP Server ist authorative und antwortet wie folgt:
Code: 
Dec 13 17:28:09 dhcp dhcpd: DHCPDISCOVER from 10:93:e9:00:c9:8a via em0
Dec 13 17:28:09 dhcp dhcpd: DHCPOFFER on 192.168.10.166 to 10:93:e9:00:c9:8a via em0
Dec 13 17:28:10 dhcp dhcpd: DHCPREQUEST for 192.168.10.166 (192.168.10.11) from 10:93:e9:00:c9:8a via em0
Dec 13 17:28:10 dhcp dhcpd: DHCPACK on 192.168.10.166 to 10:93:e9:00:c9:8a via em0
Dec 13 17:31:04 dhcp dhcpd: DHCPDISCOVER from 00:0a:eb:07:3a:65 via em0
Dec 13 17:31:05 dhcp dhcpd: DHCPOFFER on 192.168.10.161 to 00:0a:eb:07:3a:65 via em0
Dec 13 17:31:06 dhcp dhcpd: DHCPREQUEST for 192.168.178.131 (192.168.178.1) from 00:0a:eb:07:3a:65 via em0: wrong network.
Dec 13 17:31:06 dhcp dhcpd: DHCPNAK on 192.168.178.131 to 00:0a:eb:07:3a:65 via em0

Da sieht man schon die Netzwerk problematik.

All die Probleme wuerden ja wegfallen, wenn ich das LAN 2 (192.168.10.0/24) einfach ueber den Router nur nach aussen Natten lassen wuerde und LAN1 damit gar nicht reinkucken kann, und das ist auch was ich versuche, nur bekomme ich das grad nicht mit der pf sauber hin

Nachtrag:
Ich bin mir jetzt nicht sicher, ob die Jails noch weiter Internet Zugriff haben, wenn ich das gateway_enable rausnehme...
 
Ich bin mir gerade nicht zu 100% sicher ob ich das aus deinem Netzplan heraus richtig lese aber die sind schon Physikalisch voneinander getrennt?

Problem 1: Pingen
Natürlich können die Rechner aus Netz 2 die im Netz 1 Pingen und auch erreichen - halt über das NAT vom Router. Das ist so gedacht, und wirst du kaum verhindern können, ausser du baust mit der PF Regeln die jede Kommunikation verbieten ausser in Richtung router.
Du kannst ja auch hinter einem "Normalen" Nat-Router z.B. google.de pingen ...
Bei GW-Enabled bin ich mir nicht so sicher, das müsste hier einer der experten beantworten können - könnte es evtl. sein das du auch auf dem interne IF nat machen musst oder so?

Kannst du denn auch aus Netz 1 -> Netz 2 Pingen?

DHCPD
Naja aus irgend einem Grund lauscht der wohl auf beiden Schnittstellen - muss man das evtl. in der dhcpd conf einstellen oder so? Wieso eigentlich in einer Jail? Ich bin da nicht der experte da ich mich bislang noch nie mit FreeBSD beschäftigt habe, aber macht das sinn? Evtl. wäre es ja sinnvoll das ganze mal ohne Jail zu testen!

Ganz generell mal eine Frage: Warum eigentlich unbedingt "NAT" an der stelle? Würde da nicht einfach ein Gateway + Firewall regeln mehr sinn machen ohne dieses doppelte NAT?
 
Schließe mich CommanderZed an. NAT sollte nur auf der FritzBox nötig sein, nicht auf dem FreeBSD-Router. Brauchst Du überhaupt eine Kommunikation zwischen LAN1 und LAN2? Wenn nicht, dann unterbinde doch in der Firewall jeglichen Verkehr; d. h. verbiete alles, was von LAN2 nach 192.168.178.X mit X!=1 geht und umgekehrt. Dann sollten die LAN1-Clients auch keine DHCP-Antwort mehr aus dem LAN2 bekommen. Um auch umgekehrt zu verhindern, daß die LAN2-Clients eine DHCP-Antwort von der FritzBox bekommen, mußt Du explizit die Ports blockieren, nämlich UDP 67+68. Aber das sollte kaum geschehen, weil der lokale DHCP-Server schneller ist. Und bei DHCP gewinnt immer der Schnellere.
 
Du kannst dem dhcpd mitgeben, auf welchen Interfaces er arbeiten soll. Bei Dir wäre das em0.
Siehe dhcpd(8)
Ein Eintrag der Art
Code: 
dhcpd_flags="em0"
sollte Dein Problem lösen. :)
 
Naja, das Problem ist ja, dass der dhcp nur auf dem em0 lauscht.
Darum verstehe ich die ganze sache ja auch nicht.

Die Soll-Situation ist, dass Lan-1 nichts in Lan-2 erreichen darf, da dort weitere verschiedene Dienste zur verfuegung gestellt werden, wie beispielsweise Fileserver, Musicserver, etc. und ich moechte ungern bei jedem weiterem Dienst explizit eine Regel erstellen, dass diese explizit geblockt werden soll.

Eigentlich will ich nur erreichen, dass Lan-1 nicht Lan-2 sehen kann, aber Lan-2 regulaer internet bekommt. Ob das nun mit Nat oder einer pf Regel realisiert wird spielt genau genommen keine so grosse Rolle.

Ich wunder mich nur grad ueber den jetzigen Zustand, der eigtl. so nicht sein sollte. :-)
 
Ich habe ein ähnliches Szenario im Einsatz. Um auszuschließen, dass kein Zugriff vom LAN2 ins LAN1 erfolgen kann, habe ich auf dem Gateway von LAN2 (bei dir FreeBSD) pf gesagt, dass NAT nur auf das Gateway geht. Damit "sperrst" du alle anderen IPs vom LAN1 automatisch aus. Die Konfiguration kann ich dir später nachreichen.
 
Code: 
nat on $ext_if from 192.168.10.0/24 to 192.168.178.1 -> ($ext_if:0)
no nat on $ext_if from 192.168.10.0/24 to 192.168.178.0/24
nat on $ext_if from 192.168.10.0/24 -> ($ext_if:0)
Ich habe versucht die IP-Adressen auf deine Gegebenheit anzupassen und hoffe, dass es mir gelungen ist. Was ich allerdings nicht weiß: Meine Regeln sind von einem OpenBSD-Rechner. Ob pf von FreeBSD sich hier identisch verhält, weiß ich nicht (zB wegen Reihenfolge der Regeln).

HTH

Edit: Das :0 hinter dem $ext_if wirst du wohl nicht brauchen.
 
lockdoc: wenn du von lan1 kein traffic nach lan2 lassen möchtest, fehlt dir eine (generelle) block regel (mindestens) auf re0 (falls das oben tatsächlich deine ganze pf.conf sein sollte).

schau mal in das pf tutorial von Peter N. M. Hansteen. Darin werden dann auch die Besonderheiten von pf auf den unterschiedlichen Systemen behandelt.

hth
 
@Columbo0815: Danke fuer die Regeln!
@makenoob: Danke fuer die Quelle!

Ich werde es dann ausprobieren, sobald ich wieder vor Ort bin - aus der Ferne ist es immer so eine Sache mit der Firewall rumzuspielen xD

Was ich halt immer noch nicht ganz verstehe ist, warum die DHCP Anfragen ueber den Router (anderes subnetz) hinaus gehen. Sollten die udp broadcast anfragen nicht beim Router halt machen?
 
Eine Anfrage

em0 (internal)
Code: 
root> tcpdump -i em0 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:25.455966 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:46:25.456094 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

re0 (external)
Code: 
root> tcpdump -i re0 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:25.453271 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:46:25.458877 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

dhcpd.log
Man beachte das "wrong network"
Code: 
root> tail dhcpd.log
Dec 14 16:46:25 dhcp dhcpd: DHCPREQUEST for 192.168.178.125 from 98:b8:e3:78:d8:e9 via em0: [COLOR="DarkRed"]wrong network.[/COLOR]
Dec 14 16:46:25 dhcp dhcpd: DHCPNAK on 192.168.178.125 to 98:b8:e3:78:d8:e9 via em0



Weiteres

Weiteres auf em0
Code: 
C:\>tcpdump -i em0 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:25.455966 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:46:25.456094 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
16:48:58.793740 IP 192.168.10.160.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 5c:95:ae:23:36:e2, length 300
16:48:58.794550 IP 192.168.10.11.67 > 192.168.10.160.68: BOOTP/DHCP, Reply, length 300
16:48:58.803019 IP 192.168.178.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
16:49:07.248999 IP 192.168.10.154.68 > 192.168.10.11.67: BOOTP/DHCP, Request from b8:8d:12:33:82:42, length 300
16:49:07.249856 IP 192.168.10.11.67 > 192.168.10.154.68: BOOTP/DHCP, Reply, length 300
16:50:06.361212 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:50:06.362016 IP 192.168.10.11.67 > 192.168.10.152.68: BOOTP/DHCP, Reply, length 300
16:50:06.368097 IP 192.168.178.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
16:50:06.469864 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:50:06.469944 IP 192.168.10.11.67 > 192.168.10.152.68: BOOTP/DHCP, Reply, length 300
16:50:07.512217 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:50:07.513036 IP 192.168.10.11.67 > 192.168.10.152.68: BOOTP/DHCP, Reply, length 300
16:50:11.766409 IP 192.168.10.157.68 > 192.168.10.11.67: BOOTP/DHCP, Request from 00:1e:c2:b1:40:0e, length 300
16:50:11.767240 IP 192.168.10.11.67 > 192.168.10.157.68: BOOTP/DHCP, Reply, length 300
16:51:02.763494 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:02.763621 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300


Weiteres auf re0
Code: 
C:\>tcpdump -i re0 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:25.453271 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:46:25.458877 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
16:48:58.796527 IP 192.168.10.160.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 5c:95:ae:23:36:e2, length 300
16:48:58.797583 IP 192.168.178.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
16:50:06.363928 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:50:06.364584 IP 192.168.178.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
16:50:06.472624 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:50:07.514916 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 78:a3:e4:c2:3c:e5, length 300
16:51:02.760960 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:02.766429 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
16:51:30.528020 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:30.533422 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
16:51:31.649166 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:31.974857 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:33.724960 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b8:e3:78:d8:e9, length 300
16:51:33.730366 IP 192.168.10.11.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300


Weiteres dhcpd.log
Code: 
Dec 14 16:49:07 dhcp dhcpd: DHCPACK on 192.168.10.154 to b8:8d:12:33:82:42 via em0
Dec 14 16:50:06 dhcp dhcpd: DHCPREQUEST for 192.168.10.152 from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:06 dhcp dhcpd: DHCPACK on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:06 dhcp dhcpd: DHCPDISCOVER from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:06 dhcp dhcpd: DHCPOFFER on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:07 dhcp dhcpd: DHCPREQUEST for 192.168.10.152 (192.168.10.11) from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:07 dhcp dhcpd: DHCPACK on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:50:11 dhcp dhcpd: DHCPREQUEST for 192.168.10.157 from 00:1e:c2:b1:40:0e via em0
Dec 14 16:50:11 dhcp dhcpd: DHCPACK on 192.168.10.157 to 00:1e:c2:b1:40:0e via em0
Dec 14 16:51:02 dhcp dhcpd: DHCPREQUEST for 192.168.178.125 from 98:b8:e3:78:d8:e9 via em0: [COLOR="DarkRed"]wrong network.[/COLOR]
Dec 14 16:51:02 dhcp dhcpd: DHCPNAK on 192.168.178.125 to 98:b8:e3:78:d8:e9 via em0
Dec 14 16:51:30 dhcp dhcpd: DHCPREQUEST for 192.168.178.125 from 98:b8:e3:78:d8:e9 via em0: [COLOR="DarkRed"]wrong network.[/COLOR]
Dec 14 16:51:30 dhcp dhcpd: DHCPNAK on 192.168.178.125 to 98:b8:e3:78:d8:e9 via em0
Dec 14 16:51:31 dhcp dhcpd: DHCPDISCOVER from 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:51:32 dhcp dhcpd: DHCPOFFER on 192.168.10.156 to 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:51:33 dhcp dhcpd: DHCPREQUEST for 192.168.178.125 (192.168.178.1) from 98:b8:e3:78:d8:e9 via em0: [COLOR="DarkRed"]wrong network.[/COLOR]
Dec 14 16:51:33 dhcp dhcpd: DHCPNAK on 192.168.178.125 to 98:b8:e3:78:d8:e9 via em0
Dec 14 16:51:58 dhcp dhcpd: DHCPREQUEST for 192.168.178.125 from 98:b8:e3:78:d8:e9 via em0: [COLOR="DarkRed"]wrong network.[/COLOR]
Dec 14 16:51:58 dhcp dhcpd: DHCPNAK on 192.168.178.125 to 98:b8:e3:78:d8:e9 via em0
Dec 14 16:51:58 dhcp dhcpd: DHCPDISCOVER from 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:51:58 dhcp dhcpd: DHCPOFFER on 192.168.10.156 to 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:51:59 dhcp dhcpd: DHCPREQUEST for 192.168.10.156 (192.168.10.11) from 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:51:59 dhcp dhcpd: DHCPACK on 192.168.10.156 to 98:b8:e3:78:d8:e9 (Kaweh-iPhone5) via em0
Dec 14 16:52:28 dhcp dhcpd: DHCPREQUEST for 192.168.10.152 from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:52:28 dhcp dhcpd: DHCPACK on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:52:28 dhcp dhcpd: DHCPDISCOVER from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:52:28 dhcp dhcpd: DHCPOFFER on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:52:29 dhcp dhcpd: DHCPREQUEST for 192.168.10.152 (192.168.10.11) from 78:a3:e4:c2:3c:e5 via em0
Dec 14 16:52:29 dhcp dhcpd: DHCPACK on 192.168.10.152 to 78:a3:e4:c2:3c:e5 via em0
 
Jail Config

dhcpd.conf
Code: 
authoritative;
option domain-name "internal.int";
option domain-name-servers 192.168.10.10, 192.168.10.20;
local-address 192.168.10.11;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
log-facility local7;

subnet 192.168.10.0 netmask 255.255.255.0 {

        range 192.168.10.150 192.168.10.199;

        option dhcp-server-identifier 192.168.10.11;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.10.255;
        option routers 192.168.10.1;
        option netbios-node-type 8;
}


rc.conf
Code: 
dhcpd_enable="YES"
dhcpd_flags="-q"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="em0"

netstat
Code: 
udp4       0      0 192.168.10.11.67       *.*
 
@makenoob

Damit haette ich ja wieder das Problem, dass ich dann fuer jeden neu hinzukommenden Dienst explizit eine Block Regel schreiben muesste, damit man nicht in das Netzwerk rein kann.

Gibt es da nicht noch eine andere Moeglichkeit?
 
So als Alternative....

lockdoc schrieb:
* Die Fritzbox waehlt sich ins Internet ein und verteilt ueber den Internen DHCP Server die Adressen.
* Alle an der Fritzbox direkt angeschlossenen PC's sind im 192.168.178.0/24 Netz
* Ein FreeBSD Router mit 2 NICS haengt an der Fritzbox und soll ein weiteres Netz aufmachen: 192.168.10.0/24
Zum Vergrößern anklicken....
Man könnte ja auch auf der Fritzbox die Switchports auftrennen und schon da auf die Ports die zwei verschiedene Netze legen.

lockdoc schrieb:
* In dem Router laeuft eine Jail auf (em0) fuer den DHCP Server, dieser verschickt auch nur DHCP auf dem em0 (192.168.10.20) Alias Interface
Zum Vergrößern anklicken....
Dann könnte auch der DHCPd auf der Box für jedes Netz die passende IP rausgeben.
 
Was ich übersehen hatte: Das default-gateway im LAN2 darf bei "meiner Lösung" natürlich nicht auf die Fritzbox zeigen sondern muss der FreeBSD-Rechner sein.
 
lockdoc schrieb:
@makenoob

Damit haette ich ja wieder das Problem, dass ich dann fuer jeden neu hinzukommenden Dienst explizit eine Block Regel schreiben muesste, damit man nicht in das Netzwerk rein kann.

Gibt es da nicht noch eine andere Moeglichkeit?
Zum Vergrößern anklicken....

Klar, alles auf re0 blocken und nur die erwünschten Ports und Richtungen zulassen. Das hatte ich aber schon vorher geschrieben, aber schien ja nicht gewollt gewesen zu sein.
 
Hey Vielen Dank fuer die ganzen Antworten und nuetzlichen Loesungsvorschlage.

Ich werd das hier mehr oder weniger beenden, da wir auf arbeit jetzt zusaetzlich von KD eine Leitung bekommen und die Netze komplett voneinander trennen koennen.

LG :-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben