[iptables 1.3.3]nat loopback?

Pagina: 1
Acties:

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Ik achtte mezelf een ware netwerkguru, tot ik met iptables aan de slag ging.. :)

Heb een ISA2004 doos geformatteerd, en debian (2.6.15 custom kernel) erop gezet, als firewall/nat-router.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
+----------+
| INTERNET |
| Tiscali  |
+----------+
     |
     |
     | 82.171.x.x
+------------+
| HON-FRW-01 |
| NAT-router |
+------------+
     | 192.168.127.1
     |
     |-------------------+
     |                   |
     | 192.168.127.4     | 192.168.127.2
+-------------+      +--------+
|    HELIUM   |      |  XENON |
| SMTP server |      | client |
+-------------+      +--------+

NAT-routing werkt als een zonnetje, port mappings werken prima, maar ik krijg NAT-loopback niet aan de praat. Heb die smtp server op poort 25 draaien, die ik 'publish' naar het inet. Dat werkt vanaf het internet prima, maar als ik vanaf een interne client connect naar dat het externe ip van m'n firewall op poort 25, gebeurt er natuurlijk niets.. Ik wil NAT-loopback aan de praat zien te krijgen, zodat ik op mijn laptop (en die van mijn vriendin) gewoon 1 hostname (de publieke) kan invullen, waar ik on the road, en thuis gewoon mail kan sturen door die postfix smtp server. Nu zou ik een split DNS op kunnen zetten, maar ik wil het liever zo oplossen.

Als ik google op 'nat loopback', of hier op GoT, wordt ik ook niet veel wijzer. Althans, niet specifiek voor iptables.. Wat is de juiste terminologie voor dit verschijnsel? Iemand meer leesvoer over nat loopback? Of een idee hoe ik het aan de praat krijg?

Ik log zelfs nog alle blocked packets, maar daar kan ik ook niets interessants vinden.. Leuke is wel dat als ik vanuit intern telnet naar mijn publieke ip op poort 26 (die niet gebruikt wordt), krijg ik dus een logentry dat ie op de input chain geblocked wordt.. maar van poort 25 vanuit intern zie ik niets in geen enkele log terug..

Lijkt alsof het pakketje van intern wel wordt opgepikt in de PREROUTING chain, maar dan gaat er iets mis.. Weet eigenlijk niet goed hoe ik daar dan weer in kan troubleshooten.

Mijn config:
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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
#GLOBAL

#Flush all the rules in filter and nat tables
iptables --flush
iptables --table nat --flush

# delete all chains that are not in default filter and nat table
iptables --delete-chain
iptables --table nat --delete-chain

#default policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

#enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#######################################################
# LOCAL RULES
#######################################################

#allow ICMP in
iptables -A INPUT -p ICMP -j ACCEPT

#allow related traffic in
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#allow SSH in
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

#allow SNMP in from local
iptables -A INPUT -s 192.168.127.0/24 -p udp --dport 161 -j ACCEPT

#block (to keep logs clean) and log the rest incoming
iptables -A INPUT -p UDP --dport 135 -j DROP
iptables -A INPUT -p UDP --dport 137 -j DROP
iptables -A INPUT -p UDP --dport 138 -j DROP
iptables -A INPUT -p UDP --dport 139 -j DROP
iptables -A INPUT -p TCP --dport 139 -j DROP
iptables -A INPUT -p TCP --dport 445 -j DROP
iptables -A INPUT -i eth1 -d 255.255.255.255 -j DROP    #broadcasts from internet
iptables -A INPUT -d 224.0.0.0/8 -j DROP                #multicast
iptables -A INPUT -j LOG --log-level debug --log-prefix "BLOCKED INPUT: "

#######################################################
# FORWARD RULES
#######################################################


# allow certain ICMP types
iptables -A FORWARD -p ICMP --icmp-type 0 -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type 3 -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type 5 -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type 11 -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type 12 -j ACCEPT

# Set up SNAT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

#allow all outbound from local, and related back
iptables -A FORWARD -i eth0 -s 192.168.127.0/24 -j ACCEPT
iptables -A FORWARD -i eth1 -d 192.168.127.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT

#DEBUG SMTP
iptables -A INPUT -p tcp --dport 25 -j LOG --log-level debug --log-prefix "SMTP INPUT: "
iptables -A FORWARD -p tcp --dport 25 -j LOG --log-level debug --log-prefix "SMTP FORWARD: "
iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-level debug --log-prefix "SMTP OUTPUT: "

#publish SMTP > Helium
iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 192.168.127.4
iptables -A FORWARD -d 192.168.127.4 -p tcp --dport 25 -j ACCEPT

#log the rest forwarding
iptables -A FORWARD -p UDP --dport 135 -j DROP
iptables -A FORWARD -p UDP --dport 137 -j DROP
iptables -A FORWARD -p UDP --dport 138 -j DROP
iptables -A FORWARD -p UDP --dport 139 -j DROP
iptables -A FORWARD -p TCP --dport 445 -j DROP
iptables -A FORWARD -j LOG --log-level debug --log-prefix "BLOCKED FORWARD: "

echo "Firewall rules applied.."


code:
1
2
3
4
5
6
7
8
9
10
11
12
hon-frw-01:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere            tcp dpt:smtp to:192.168.127.4

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
hon-frw-01:~#


Kom er nu trouwens achter dat als ik nog meer log met:
code:
1
2
3
4
5
6
iptables -A OUTPUT  -j LOG --log-level debug --log-prefix "SMTP OUTPUT: "
iptables -A INPUT   -j LOG --log-level debug --log-prefix "SMTP INPUT: "
iptables -A FORWARD -j LOG --log-level debug --log-prefix "SMTP FORWARD: "
iptables -t nat -A PREROUTING  -j LOG --log-level debug --log-prefix "SMTP NAT PREROUTING: "
iptables -t nat -A POSTROUTING -j LOG --log-level debug --log-prefix "SMTP NAT POSTROUTING: "
iptables -t nat -A OUTPUT -j LOG --log-level debug --log-prefix "SMTP NAT OUTPUT: "


Dat ik het bewuste pakketje wel zie op de NAT POSTROUTING chain:
code:
1
Feb 27 15:13:06 localhost kernel: SMTP NAT POSTROUTING: IN= OUT=eth0 SRC=192.168.127.2 DST=192.168.127.4 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=36578 PROTO=TCP SPT=19369 DPT=25 WINDOW=64240 RES=0x00 SYN URGP=0


En als ik dan ga sniffen op mijn smtp server (helium, 192.168.127.4)
code:
1
2
3
4
5
6
7
8
9
10
11
12
15:12:07.606288 IP xenon.19400 > xxxxxxxxx.dsl.ip.tiscali.nl.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:07.606428 IP xenon.19400 > helium.hongens.local.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:07.606539 IP helium.hongens.local.smtp > xenon.19400: S 957057289:957057289(0) ack 1063560207 win 5840 <mss 1460,nop,nop,sackOK>
15:12:07.607046 IP xenon.19400 > helium.hongens.local.smtp: R 1063560207:1063560207(0) win 0
15:12:10.587902 IP xenon.19400 > 82-171-164-250.dsl.ip.tiscali.nl.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:10.588062 IP xenon.19400 > helium.hongens.local.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:10.588123 IP helium.hongens.local.smtp > xenon.19400: S 960038870:960038870(0) ack 1063560207 win 5840 <mss 1460,nop,nop,sackOK>
15:12:10.588702 IP xenon.19400 > helium.hongens.local.smtp: R 1063560207:1063560207(0) win 0
15:12:16.530279 IP xenon.19400 > 82-171-164-250.dsl.ip.tiscali.nl.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:16.530380 IP xenon.19400 > helium.hongens.local.smtp: S 1063560206:1063560206(0) win 64240 <mss 1460,nop,nop,sackOK>
15:12:16.530428 IP helium.hongens.local.smtp > xenon.19400: S 965981178:965981178(0) ack 1063560207 win 5840 <mss 1460,nop,nop,sackOK>
15:12:16.531257 IP xenon.19400 > helium.hongens.local.smtp: R 1063560207:1063560207(0) win 0

Dan zie ik dat daar de pakketjes wel aankomen vanaf mijn client (xenon, 192.168.127.2), en dat er wel een reply gestuurd wordt naar de client.

Als ik dan op xenon ga lopen sniffen met ethereal (win32 doos) zie ik het volgende.. Ze communiceren dus wel, maar toch ook weer niet, ik krijg niet netjes de SMTP header op mijn client, er gaat toch iets mis in de communicatie.. Iemand enig idee??
code:
1
2
3
4
5
6
7
8
9
10
No.     Time        Source                Destination           Protocol Info
      5 1.124425    192.168.127.2         192.168.127.4         TCP      19551 > smtp [SYN] Seq=0 Ack=0 Win=64240 Len=0 MSS=1460
      6 1.124433    192.168.127.4         192.168.127.2         TCP      smtp > 19551 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
      7 1.125200    192.168.127.2         192.168.127.4         TCP      19551 > smtp [RST] Seq=1 Ack=1806634885 Win=0 Len=0
      8 4.073877    192.168.127.2         192.168.127.4         TCP      19551 > smtp [SYN] Seq=0 Ack=0 Win=64240 Len=0 MSS=1460
      9 4.074058    192.168.127.4         192.168.127.2         TCP      smtp > 19551 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
     10 4.076586    192.168.127.2         192.168.127.4         TCP      19551 > smtp [RST] Seq=1 Ack=1803665674 Win=0 Len=0
     13 9.978359    192.168.127.2         192.168.127.4         TCP      19551 > smtp [SYN] Seq=0 Ack=0 Win=64240 Len=0 MSS=1460
     14 9.978367    192.168.127.4         192.168.127.2         TCP      smtp > 19551 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
     15 9.978424    192.168.127.2         192.168.127.4         TCP      19551 > smtp [RST] Seq=1 Ack=1797724665 Win=0 Len=0

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


  • Buffy
  • Registratie: April 2002
  • Laatst online: 26-12-2024

Buffy

Fire bad, Tree pretty

Het 'probleem' is dat je SMTP server rechtstreeks met de interne client probeert te communiceren welke dat niet verwacht omdat hij met 82.171.x.x:25 verbonden denkt te zijn ipv van 192.168.127.4:25

Je zult dus op de NAT router redirects van het interne netwerk naar de SMTP-server ook moeten Source-NAT'en zodat de SMTP server via de NAT router communiceert met de interne client. De SMTP server denkt dan wel dat de connectie afkomstig is van de NAT router (die de communicatie weer doorsluist naar de interne client).

Waarschijnlijk wordt het zoiets:
code:
1
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.127.0/24 -d 192.168.127.4 -j SNAT --to-source 192.168.127.1

[ Voor 15% gewijzigd door Buffy op 27-02-2006 16:25 ]

That which doesn't kill us, makes us stranger - Trevor (AEon FLux)
When a finger points at the moon, the imbecile looks at the finger (Chinese Proverb)


  • MTWZZ
  • Registratie: Mei 2000
  • Laatst online: 13-08-2021

MTWZZ

One life, live it!

Beter googlen
3e hit :)
of direct

[ Voor 31% gewijzigd door MTWZZ op 27-02-2006 16:13 ]

Nu met Land Rover Series 3 en Defender 90


  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Dawns_sister schreef op maandag 27 februari 2006 @ 16:09:
Het 'probleem' is dat je SMTP server rechtstreeks met de interne client probeert te communiceren welke dat niet verwacht omdat hij met 82.171.x.x:25 verbonden denkt te zijn ipv van 192.168.127.4:25

Je zult dus op de NAT router redirects van het interne netwerk naar de SMTP-server ook moeten Source-NAT'en zodat de SMTP server via de NAT router communiceert met de interne client. De SMTP server denkt dan wel dat de connectie afkomstig is van de NAT router (die de communicatie weer doorsluist naar de interne client).

Waarschijnlijk wordt het zoiets:
code:
1
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.127.0/24 -d 192.168.127.4 -j SNAT --to-source 192.168.127.1
Zo.. duurde even voor ik 'm doorhad, maar inderdaad, ik snap um! En het werkt als een zonnetje.. Dank je dat je voor de oplossing! (en dat je mijn ellenlange post doorleest ;) )
Was deze pagina al tegengekomen, alleen dacht dat dat niet van toepassing was, omdat het ging over users op localhost die de publieke hostname wilde gebruiken, iets andere situatie..

[ Voor 21% gewijzigd door axis op 27-02-2006 17:07 ]

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


  • MTWZZ
  • Registratie: Mei 2000
  • Laatst online: 13-08-2021

MTWZZ

One life, live it!

axis schreef op maandag 27 februari 2006 @ 17:06:
[...]

Zo.. duurde even voor ik 'm doorhad, maar inderdaad, ik snap um! En het werkt als een zonnetje.. Dank je dat je voor de oplossing! (en dat je mijn ellenlange post doorleest ;) )


[...]

Was deze pagina al tegengekomen, alleen dacht dat dat niet van toepassing was, omdat het ging over users op localhost die de publieke hostname wilde gebruiken, iets andere situatie..
Mja klopt maar het werkt ook voor alles op m'n interne netwerk :P

Nu met Land Rover Series 3 en Defender 90