[ipmasqadm] portfw extern wel, intern niet

[corani]

Nadat ik de kernel voor m'n firewall opnieuw gecompileerd heb (debian alpha heeft default geen portfw module ) kan ik netjes een poort forwarden naar een systeem binnen het netwerk.

Leuk dus, maar nu zit ik nog met het probleem dat als je van het interne netwerk naar de de firewall gaat, op de juiste poort, dat het dan niet werkt.

Ik heb gezocht hier, en kwam alleen de oplossing van Nelske tegen. Hij raad aan om de interne DNS aan te passen, maar dat is in dit geval *geen* oplossing. Er wordt vanuit de firewall namelijk naar verschillende servers geforward.

In de HOWTO's vond ik dit:

code:

>If I use:
>
> ipmasqadm portfw -a -P tcp  -L 1.2.3.4 80 -R 192.168.2.3 80
>
>Everything works great from the outside but internal requests for the same
>1.2.3.4 address fail. Are there chains that will allow a machine on localnet 
>192.168.2.0 to accesss www.periapt.com without using a proxy? 

Actually not.

I usually setup a ipmasqadm rule for outside, *AND* a port
redirector for inside. This works because ipmasqadm hooks before
redir will get the eventual outside connection, _but_ leaves things
ok if not (stated by APPROPIATE rules).

The actual "conceptual" problem comes from the TRUE client (peer) IP
goal (thanks to masq) being in the same net as target server.

The failing scenario for "local masq" is :
   client: 192.168.2.100
   masq:   192.168.2.1
   serv:   192.168.2.10

1)client->server packet
 a) client:  192.168.2.100:1025  -> 192.168.2.1:80   [SYN]
 b) (masq):  192.168.2.100:1025  -> 192.168.2.10:80  [SYN]
        (and keep  192.168.2.1:61000 192.168.2.100:1025 related)
 c) serv:    gets masqed packet (1b)

2)server->client packet
 a) serv:    192.168.2.10:80     -> 192.168.2.100:1025  [SYN,ACK]
 b) client:  192.168.2.100:1025  -> 192.168.2.10:80     [RST]

Now take a moment to compare (1a) with (2a).
You see, the server replied DIRECTLY to client bypassing masq (not
letting masq to UNDO the packet hacking) because it is in SAME net, so
the client resets the connection.

Maar ik snap dus niet hoe ik dit moet implementeren.

Voor de duidelijkheid, als je van buiten naar de firewall gaat, wordt je netjes geredirect, maar van het interne netwerk niet. Ik denk wel ongeveer te snappen waarom het niet werkt, maar ik weet niet hoe ik dit kan oplossen.

En voordat mensen oplossingen met iptables beginnen te roepen: ik gebruik ipchains, en was niet van plan te updaten

[corani]

uhm... niemand?

[Verwijderd]

Wat hier wordt voorgesteld is dat je ipmasqadm gebruikt voor de forwarding vanaf externe ip's en redir voor interne ip's. Redir moet je dan niet in transparante modus gebruiken, maar als proxy. Redir zal dan zelf een connectie opzetten en zal de server waarna je connect alleen het ip van de firewall zien en dus weer naar de firewall replyen.

Hoe zou het moeten werken:

ipchains rules opzetten voor alle externe verkeer en markeren (-m 1 bijv)
-A input -s !10.0.0.0/24 -d $extip 22 -p tcp -j ACCEPT -m 1
ipmasqadm rules opzetten voor de mfw optie voor mark 1 (de -m 1 van ipchains) dus in dit geval:
-A -m 1 -r $interneserverip port
redir installeren en als proxy gebruiken voor interne redirs.
--laddr $extip --lport 22 --raddr $interneserverip --rport $svrport

Ikheb dit zelf overigens niet getest....


Overigens als het source address van je externe bezoekers je niets kan schelen kun je gewoon redir gebruiken zonder ander gedoe. Alle connecties 'lijken' dan van je firewall te komen.