iptables dnat naar andere poort

[Trax_Digitizer]

Ik probeer al een paar uur het volgende aan de praat te krijgen:

Via iptables wil ik binnenkomende connecties op poort 81 forwarden naar een interne machine (accesspoint) op poort 80. Ik draai een webserver op poort 80, en ik wil van buitenaf de webinterface van mijn accesspoint benaderen.

Ik heb netfilter.org erop nageslagen en gezocht op google. Als ik al voorbeelden vind waarbij de 'destination poort' (in dit geval poort 80) afwijkt van de 'dnat poort' (in dit geval poort 81), dan bevestigen deze voorbeelden alleen maar dat ik het goed heb ingesteld. Namelijk gewoon de reguliere port forwarding rules, maar dan een andere poort bij DNAT. Dit dus:

code:

WIFI_SERVER="192.168.1.2"
WIFI_PORT_EXT="81"
WIFI_PORT_INT="80"
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE --dport $WIFI_PORT_EXT -j DNAT --to $WIFI_SERVER:$WIFI_PORT_INT
$IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -d $WIFI_SERVER -p TCP --dport $WIFI_PORT_INT -j ACCEPT

Helaas geeft dit niet het gewenste resultaat. Geeft een time-out. Dit stukje script werkt overigens al jaren prima als het dezelfde poort betreft, maar nu ik de poort wil veranderen, werkt het niet. Ik zie niet waarom het niet werkt. Ik heb al zitten denken dat het "retour pakketje" wellicht niet goed gaat, maar daar kan ik geen rules voor opzetten, omdat de sourceport en het ip-adres van de client niet weet.

Iemand suggesties?

[TrailBlazer]

even tcpdump draaien en kijken wat er gebeurt. Overigens mijn gok is dat het AP of geen default gateway heeft of dat hij geen management van buiten zijn eigen subnet toestaat.
Als dat het geval is kan je nog een POSTROUTING doen waarbij je het verkeer naar je AP nog even nat over de interne interface.

code:

$IPTABLES -t nat -A PREROUTING  -p tcp -d $modemip --dport 8080 -j DNAT --to 192.168.101.131:80
$IPTABLES -t filter -A FORWARD -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -d 192.168.101.131 -o eth0.101 -j MASQUERADE

Dit zijn mijn rules. Ik accepteer in principe alles in de FORWARD chain. Die laatste nat nog even alles naar het interne adres van mijn firewall.

[Trax_Digitizer]

Die masquerade regel heb ik al in mijn script zitten. Op de volgende manier:

code:

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -s $LAN_IP_RANGE -j MASQUERADE

Met tcpdump zie ik inderdaad dat het request wordt doorgezet naar mijn accesspoint, maar dat er niks terug komt. Dit betekent dus dat mijn iptables scriptje gewoon klopt, maar dat het probleem bij mijn access point zit. Even voor de beeldvorming: mijn access point is een Linksys WRT54GL die ik met behulp van DD-WRT (v23 SP2) heb geconfigureerd als Wireless Access Point.

Het "router management menu" op mijn linksys kent web access en remote access. Om er zeker van te zijn dat het subnet probleem niet speelt heb ik remote access aangezet op poort 8080 (. Toen kwam ik erachter dat als ik gewoon poort 8080 forward zoals ik dat altijd doe (dus zonder poortverschillen), het ook niet werkt.

Dit lijkt te impliceren dat de firewall op mijn Linksys niet mee wil werken. Ik heb echter nog geen "harde bewijzen" kunnen vinden dat dit daadwerkelijk het geval is.

[TrailBlazer]

Nee dit is de verkeerde kant op genat vanaf je lan naar internet toe.
De output interface is $LAN_IFACE en de source kan je weglaten. Wel even een destination ip er bij zetten zoals ik in mijn voorbeeld doe.

code:

$IPTABLES -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0.2 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -s 192.168.101.0/24 -o eth0.2 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -d 192.168.101.131 -o eth0.101 -j MASQUERADE

Hierboven zijn al mijn relevante nat regels. De bovenste twee zijn voor mijn 2 interne netwerken. Internet zit op poort eth0.2. De laatste regel nat al het verkeer naar 192.168.101.131 zodat deze pakketten de source krijgen van 192.168.101.254

code:

epia:~# ifconfig eth0.101
eth0.101  Link encap:Ethernet  HWaddr 00:40:63:cb:a1:24
          inet addr:192.168.101.254  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: 2001:470:d13d:65::1/64 Scope:Global
          inet6 addr: fe80::240:63ff:fecb:a124/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2528490 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4397843 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:240714095 (229.5 MiB)  TX bytes:2799397187 (2.6 GiB)

epia:~#

[Trax_Digitizer]

Je hebt inderdaad gelijk, maar nog steeds werkt het niet. Even de tcpdump als bevestiging:

Nu volgende iptables scriptje (heb de poorten voor het testen even gelijk aan elkaar gemaakt).

code:

WIFI_SERVER="192.168.1.2"
WIFI_PORT_EXT="8080"
WIFI_PORT_INT="8080"
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE --dport $WIFI_PORT_EXT -j DNAT --to $WIFI_SERVER:$WIFI_PORT_INT
$IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -d $WIFI_SERVER -p TCP --dport $WIFI_PORT_INT -j ACCEPT
#$IPTABLES -t nat -A POSTROUTING -o $LAN_IFACE -d $WIFI_SERVER -j MASQUERADE

Met MASQUERADE regel

code:

11:29:16.386496 IP 192.168.1.1.50474 > 192.168.1.2.8080: S 2598993440:2598993440(0) win 65535 <mss 1360,nop,nop,sackOK>

Zonder MASQUERADE regel (ip-adres van de baas (ik test via VPN vanaf kantoor) even onherkenbaar gemaakt):

code:

11:30:19.080532 IP XXX.XXX.73.50.50557 > 192.168.1.2.8080: S 1319512760:1319512760(0) win 65535 <mss 1360,nop,nop,sackOK>

Is het nu veilig te concluderen dat mijn iptables script het probleem niet is? Ik neig wel naar deze stelling, maar vind het raar dat ik vanaf mijn desktop (192.168.1.4) wel gewoon de webinterface via poort 80 en via poort 8080 (als gevolg van remote access) kan benaderen. Dan zou ik toch denken dat het nu ook vanaf extern moet lukken. De pakketjes zijn namelijk zo aangepast dat mijn Linksys het verschil niet ziet.

Er moet iets zijn wat ik over het hoofd zie, dat kan bijna niet anders... ik ga mijn hele iptables script nog een keer goed doorlezen.

[TrailBlazer]

dat lijkt me ook ja. Ik gebruik deze constructie ook om een device via het net te benaderen wat ik anders niet kon. Je ziet ook nergens in je firewall paketten gedropped worden neem ik aan. Eventueel kan je in je input chain bovenaan een log zetten voor al het verkeer vanaf dat ip adres.

[Trax_Digitizer]

Ik zit hier de haren uit mijn hoofd te trekken, maar ik ben eruit! Het probleem was dat ik een mac-address acceptance filter op de LAN interface van mijn server heb draaien. Omdat de LAN interface van mijn accesspoint niet op internet hoeft, had ik deze niet toegevoegd. Maar ja, dan worden dus ook de retourpakketjes tegen gehouden!

Het werkt nu perfect. Door testen ben ik erachter gekomen dat de masquerading-regel niet nodig is, omdat mijn linksys niet alleen subnet ip's toelaat. Het poort 81 naar poort 80 verhaal heb ik nu dus gewoon werkend!

TrailBlazer: hartelijk bedankt voor het meedenken. Was erg nuttig! Nu heb ik tenminste die masquerading regel achter de hand mocht ik hem nog eens nodig hebben.

[TrailBlazer]

Graag gedaan hoor. Eindelijk weer eens een topic op niveau Ik gebruik die masquerade regel wel vaker omdat ik een achterlijk complex netwerk heb met iets van 4 of 5 subnets/vlans