* iptables - external IP address on internal interface?
@ 2011-04-11 14:04 Tony Rogers
2011-04-11 14:42 ` Usuário do Sistema
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Tony Rogers @ 2011-04-11 14:04 UTC (permalink / raw)
To: netfilter
I have a question for the iptables experts out there.
I previously asked this question on this forum here.
But no satisfactory answer was given.
I have an iptables firewall, where *eth0* is the *internal interface*,
and _eth1 is the external interface_. eth1 is connected directly to the
internet, and this box is also a NAT router.
I am seeing traffic sourced from external IP addresses on eth0 (internal
interface) - how can this be? (see logs below)
Is there a rule I can add to prevent this?
---- log entries below -------------
Logged 663 packets on interface eth0
From 74.217.240.81 - 181 packets to
tcp(2666,2674,2683,2685,2689,2694,2700,2704,2796,2799,2801,2806,2811,285
2,2860,2863,2868,2876,2877,2882,2886,2887,2892,2920,2926,2930,2942,2948,
3251,3253,3261,3268,3274,3286,3290,3293,3295,3300,3380,3425,3461,3559,36
21,3659,3686,3711)
From 74.217.240.83 - 14 packets to tcp(1572)
From 212.118.226.90 - 174 packets to
tcp(2365,2382,2462,2467,2479,2485,2522,2539,2550,2570,2599,2604,2610,262
7,2637,2642,2668,2684,2686,2690,2696,2701,2743,2751,2763,2783,2802,2807,
2813,2861,2875,2884,2893,2921,2941,2957,2969,2986,3015,3041,3045,3051,31
95,3240,3241,3252,3254,3269,3287,3301)
From 212.118.226.91 - 271 packets to
tcp(1408,1444,1484,1506,1521,1528,2300,2356,2364,2384,2460,2466,2470,248
4,2523,2538,2544,2569,2575,2598,2601,2626,2643,2647,2742,2744,2753,2757,
2762,2766,2773,2781,2784,2789,2950,2954,2956,3005,3013,3017,3027,3032,30
40,3044,3050,3194,3202,3211,3228,3235,3239,3305,3467,3494,3506,3526,3536
,3719,3727,3813)
From 212.118.226.93 - 23 packets to tcp(1419,1495,4362,4385,4416)
Logged 632 packets on interface eth1
From 1.112.169.252 - 2 packets to tcp(445)
From 2.201.14.207 - 3 packets to tcp(445)
From 14.96.161.61 - 2 packets to tcp(445)
From 17.172.237.52 - 2 packets to tcp(49641)
<snip>
------------------------
This email was scanned by BitDefender.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: iptables - external IP address on internal interface? 2011-04-11 14:04 iptables - external IP address on internal interface? Tony Rogers @ 2011-04-11 14:42 ` Usuário do Sistema 2011-04-11 14:53 ` Jan Engelhardt 2011-04-11 17:52 ` Andrew Beverley 2 siblings, 0 replies; 13+ messages in thread From: Usuário do Sistema @ 2011-04-11 14:42 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter Tony, I think your case it's normal because there is no an NAT for packages from Internet to your Inside Network. for exmplo, when a user , inside your network, accesses Internet there is a NAT only for out when the packages returns ( from Internet ) there is no a NAT so you always will see return packages from Internet on your inside network.the packages from Internet arrives on user machine with an public IP address. bye. 2011/4/11 Tony Rogers <Tony.Rogers@erudine.com>: > > I have a question for the iptables experts out there. > > I previously asked this question on this forum here. > > But no satisfactory answer was given. > > I have an iptables firewall, where *eth0* is the *internal interface*, > and _eth1 is the external interface_. eth1 is connected directly to the > internet, and this box is also a NAT router. > > I am seeing traffic sourced from external IP addresses on eth0 (internal > interface) - how can this be? (see logs below) > > Is there a rule I can add to prevent this? > > ---- log entries below ------------- > > Logged 663 packets on interface eth0 > From 74.217.240.81 - 181 packets to > tcp(2666,2674,2683,2685,2689,2694,2700,2704,2796,2799,2801,2806,2811,285 > 2,2860,2863,2868,2876,2877,2882,2886,2887,2892,2920,2926,2930,2942,2948, > 3251,3253,3261,3268,3274,3286,3290,3293,3295,3300,3380,3425,3461,3559,36 > 21,3659,3686,3711) > From 74.217.240.83 - 14 packets to tcp(1572) > From 212.118.226.90 - 174 packets to > tcp(2365,2382,2462,2467,2479,2485,2522,2539,2550,2570,2599,2604,2610,262 > 7,2637,2642,2668,2684,2686,2690,2696,2701,2743,2751,2763,2783,2802,2807, > 2813,2861,2875,2884,2893,2921,2941,2957,2969,2986,3015,3041,3045,3051,31 > 95,3240,3241,3252,3254,3269,3287,3301) > From 212.118.226.91 - 271 packets to > tcp(1408,1444,1484,1506,1521,1528,2300,2356,2364,2384,2460,2466,2470,248 > 4,2523,2538,2544,2569,2575,2598,2601,2626,2643,2647,2742,2744,2753,2757, > 2762,2766,2773,2781,2784,2789,2950,2954,2956,3005,3013,3017,3027,3032,30 > 40,3044,3050,3194,3202,3211,3228,3235,3239,3305,3467,3494,3506,3526,3536 > ,3719,3727,3813) > From 212.118.226.93 - 23 packets to tcp(1419,1495,4362,4385,4416) > > Logged 632 packets on interface eth1 > From 1.112.169.252 - 2 packets to tcp(445) > From 2.201.14.207 - 3 packets to tcp(445) > From 14.96.161.61 - 2 packets to tcp(445) > From 17.172.237.52 - 2 packets to tcp(49641) > <snip> > > ------------------------ > This email was scanned by BitDefender. > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-11 14:04 iptables - external IP address on internal interface? Tony Rogers 2011-04-11 14:42 ` Usuário do Sistema @ 2011-04-11 14:53 ` Jan Engelhardt 2011-04-11 17:52 ` Andrew Beverley 2 siblings, 0 replies; 13+ messages in thread From: Jan Engelhardt @ 2011-04-11 14:53 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter On Monday 2011-04-11 16:04, Tony Rogers wrote: > >I have a question for the iptables experts out there. > >I previously asked this question on this forum here. > >But no satisfactory answer was given. > >I have an iptables firewall, where *eth0* is the *internal interface*, >and _eth1 is the external interface_. eth1 is connected directly to the >internet, and this box is also a NAT router. > >I am seeing traffic sourced from external IP addresses on eth0 (internal >interface) - how can this be? (see logs below) A misconfigured host. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-11 14:04 iptables - external IP address on internal interface? Tony Rogers 2011-04-11 14:42 ` Usuário do Sistema 2011-04-11 14:53 ` Jan Engelhardt @ 2011-04-11 17:52 ` Andrew Beverley 2011-04-12 9:20 ` Tony Rogers 2 siblings, 1 reply; 13+ messages in thread From: Andrew Beverley @ 2011-04-11 17:52 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter On Mon, 2011-04-11 at 15:04 +0100, Tony Rogers wrote: > I have a question for the iptables experts out there. > > I previously asked this question on this forum here. > > But no satisfactory answer was given. > > I have an iptables firewall, where *eth0* is the *internal interface*, > and _eth1 is the external interface_. eth1 is connected directly to the > internet, and this box is also a NAT router. > > I am seeing traffic sourced from external IP addresses on eth0 (internal > interface) - how can this be? (see logs below) Can you post the iptables rules that you are using, in particular the NAT part? What IP address range are you using on the internal network? Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: iptables - external IP address on internal interface? 2011-04-11 17:52 ` Andrew Beverley @ 2011-04-12 9:20 ` Tony Rogers 2011-04-12 19:26 ` Andrew Beverley [not found] ` <1302626146.4938.1.camel@andybev-desktop> 0 siblings, 2 replies; 13+ messages in thread From: Tony Rogers @ 2011-04-12 9:20 UTC (permalink / raw) To: Andrew Beverley; +Cc: netfilter As requested - output of "iptables -nL" I have sanitized this to a certain extent: 192.168.0.2 is a VoIP box (and proven not to be the source of any of this traffic). <EXT_IP> is the external IP of the box. <ACCESS_IP_1> through <ACCESS_IP_7> are static addresses giving access to certain services. <ACCESS_NET> is a static network address giving access to certain services. ------------------------------------------------------------------------ ----------------------------- Chain INPUT (policy DROP) target prot opt source destination DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:1026:1028 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:1026:1028 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 BADTCP all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW ACCEPT !icmp -- 0.0.0.0/0 0.0.0.0/0 state NEW XTACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 5 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec burst 5 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `INPUT ' ACCEPT udp -- 0.0.0.0/0 224.0.0.0/4 ACCEPT 2 -- 0.0.0.0/0 224.0.0.0/4 DROP all -- 0.0.0.0/0 224.0.0.0/4 DROP all -- 224.0.0.0/4 0.0.0.0/0 DROP all -- 240.0.0.0/4 0.0.0.0/0 Chain FORWARD (policy DROP) target prot opt source destination BADTCP all -- 0.0.0.0/0 0.0.0.0/0 TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW PORTFWACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `OUTPUT ' ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpt:5060 ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpts:1024:65535 ACCEPT tcp -- <ACCESS_NET>/28 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_NET>/28 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:20 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:21 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain BADTCP (2 references) target prot opt source destination PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x01 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03 NEWNOTSYN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW Chain LOG_DROP (0 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain LOG_REJECT (0 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain NEWNOTSYN (1 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain PORTFWACCESS (1 references) target prot opt source destination Chain PSCAN (5 references) target prot opt source destination LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `TCP Scan? ' LOG udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `UDP Scan? ' LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `ICMP Scan? ' LOG all -f 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `FRAG Scan? ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain XTACCESS (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:20 state NEW ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:21 state NEW ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:80 state NEW ACCEPT tcp -- <ACCESS_IP_5> <EXT_IP> tcp dpt:5000 state NEW ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpts:1024:65535 ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpt:5060 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:223 ACCEPT tcp -- <ACCESS_IP_1> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:81 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:223 ACCEPT tcp -- <ACCESS_IP_2> <EXT_IP> state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:10000 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:10000 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:5901 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:5901 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:5900 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:5900 ------------------------------------------------------------------------ ------------------------------------------------------- -----Original Message----- From: Andrew Beverley [mailto:andy@andybev.com] Sent: 11 April 2011 18:53 To: Tony Rogers Cc: netfilter@vger.kernel.org Subject: Re: iptables - external IP address on internal interface? On Mon, 2011-04-11 at 15:04 +0100, Tony Rogers wrote: > I have a question for the iptables experts out there. > > I previously asked this question on this forum here. > > But no satisfactory answer was given. > > I have an iptables firewall, where *eth0* is the *internal interface*, > and _eth1 is the external interface_. eth1 is connected directly to the > internet, and this box is also a NAT router. > > I am seeing traffic sourced from external IP addresses on eth0 (internal > interface) - how can this be? (see logs below) Can you post the iptables rules that you are using, in particular the NAT part? What IP address range are you using on the internal network? Andy ------------------------ This email was scanned by BitDefender. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: iptables - external IP address on internal interface? 2011-04-12 9:20 ` Tony Rogers @ 2011-04-12 19:26 ` Andrew Beverley 2011-04-12 20:31 ` Robert Nichols [not found] ` <1302626146.4938.1.camel@andybev-desktop> 1 sibling, 1 reply; 13+ messages in thread From: Andrew Beverley @ 2011-04-12 19:26 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter > > Can you post the iptables rules that you are using, in particular the > > NAT part? What IP address range are you using on the internal network? > > As requested - output of "iptables -nL" > Having scanned the list of rules (which were pretty difficult to read due to line wrapping) I cannot see any SNAT/MASQUERADE targets? If so, I would have thought that the behaviour you are seeing is to be expected. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-12 19:26 ` Andrew Beverley @ 2011-04-12 20:31 ` Robert Nichols 0 siblings, 0 replies; 13+ messages in thread From: Robert Nichols @ 2011-04-12 20:31 UTC (permalink / raw) To: netfilter On 04/12/2011 02:26 PM, Andrew Beverley wrote: > >>> Can you post the iptables rules that you are using, in particular the >>> NAT part? What IP address range are you using on the internal network? >> >> As requested - output of "iptables -nL" >> > > Having scanned the list of rules (which were pretty difficult to read > due to line wrapping) I cannot see any SNAT/MASQUERADE targets? If so, I > would have thought that the behaviour you are seeing is to be expected. The command "iptables -nL" will show only the "filter" table, so of course there are no NAT rules shown. The output from "iptables-save" will be all-inclusive. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <1302626146.4938.1.camel@andybev-desktop>]
[parent not found: <054F5B1BB94BD943B243C3B39B4F568D0161B8F7@victory.Erudine.local>]
[parent not found: <1302636161.4938.5.camel@andybev-desktop>]
* Re: iptables - external IP address on internal interface? [not found] ` <1302636161.4938.5.camel@andybev-desktop> @ 2011-04-12 21:37 ` Tony Rogers 2011-04-14 20:24 ` Andrew Beverley 0 siblings, 1 reply; 13+ messages in thread From: Tony Rogers @ 2011-04-12 21:37 UTC (permalink / raw) To: Andrew Beverley; +Cc: netfilter On 12/04/2011 20:22, Andrew Beverley wrote: > On Tue, 2011-04-12 at 20:12 +0100, Tony Rogers wrote: >> >> >> -----Original Message----- >> From: Andrew Beverley [mailto:andy@andybev.com] >> Sent: 12 April 2011 17:36 >> To: Tony Rogers >> Subject: RE: iptables - external IP address on internal interface? >> >> On Tue, 2011-04-12 at 10:20 +0100, Tony Rogers wrote: >>> As requested - output of "iptables -nL" >>> >> >> Any chance that you can re-post that without the line wrapping please? >> It's almost impossible to read. A bottom-post would be nice as well :-) >> >> Thanks, >> >> Andy >> >> >> Hi Andy, >> >> Let me try this again then! > > Hmmm, still a mess I'm afraid, I think you should try a different email > client that is list friendly... > >> (only replying to you directly rather than >> the entire list this time) >> > > However, having skimmed through the rules, I cannot see any NAT targets > in there? If so, the behaviour you are seeing is to be expected. > > I'll reply the same to the list. > > Andy > > > > ------------------------ > This email was scanned by BitDefender. Ok, trying with Thunderbird this time... (and it too seems to be wrapping the text) <sigh> *** NAT rules *** Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT udp -- 0.0.0.0/0 <EXT_IP> udp dpt:5060 to:192.168.0.2:5060 DNAT udp -- 0.0.0.0/0 <EXT_IP> udp dpts:1024:65535 to:192.168.0.2:1024-65535 DNAT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:80 to:192.168.0.2:80 DNAT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:22 to:192.168.0.2:22 DNAT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:20 to:192.168.0.2:20 DNAT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:21 to:192.168.0.2:21 Chain POSTROUTING (policy ACCEPT) target prot opt source destination REDNAT all -- 0.0.0.0/0 0.0.0.0/0 SNAT all -- 0.0.0.0/0 0.0.0.0/0 MARK match 0x1 to:192.168.0.1 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain REDNAT (1 references) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 *** output of iptables -nL *** Chain INPUT (policy DROP) target prot opt source destination DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:1026:1028 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:1026:1028 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 BADTCP all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW ACCEPT !icmp -- 0.0.0.0/0 0.0.0.0/0 state NEW XTACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 5 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec burst 5 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `INPUT ' ACCEPT udp -- 0.0.0.0/0 224.0.0.0/4 ACCEPT 2 -- 0.0.0.0/0 224.0.0.0/4 DROP all -- 0.0.0.0/0 224.0.0.0/4 DROP all -- 224.0.0.0/4 0.0.0.0/0 DROP all -- 240.0.0.0/4 0.0.0.0/0 Chain FORWARD (policy DROP) target prot opt source destination BADTCP all -- 0.0.0.0/0 0.0.0.0/0 TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW DROP all -- 127.0.0.0/8 0.0.0.0/0 state NEW DROP all -- 0.0.0.0/0 127.0.0.0/8 state NEW ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW PORTFWACCESS all -- 0.0.0.0/0 0.0.0.0/0 state NEW LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `OUTPUT ' ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpt:5060 ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpts:1024:65535 ACCEPT tcp -- <ACCESS_NET>/28 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:80 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_NET>/28 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:20 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 tcp dpt:21 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain BADTCP (2 references) target prot opt source destination PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x01 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06 PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03 NEWNOTSYN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW Chain LOG_DROP (0 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain LOG_REJECT (0 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain NEWNOTSYN (1 references) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain PORTFWACCESS (1 references) target prot opt source destination Chain PSCAN (5 references) target prot opt source destination LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `TCP Scan? ' LOG udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `UDP Scan? ' LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `ICMP Scan? ' LOG all -f 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `FRAG Scan? ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain XTACCESS (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:20 state NEW ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:21 state NEW ACCEPT tcp -- 0.0.0.0/0 <EXT_IP> tcp dpt:80 state NEW ACCEPT tcp -- <ACCESS_IP_5> <EXT_IP> tcp dpt:5000 state NEW ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpts:1024:65535 ACCEPT udp -- <ACCESS_IP_7> 192.168.0.2 udp dpt:5060 ACCEPT tcp -- <ACCESS_IP_3> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_4> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:223 ACCEPT tcp -- <ACCESS_IP_1> 192.168.0.2 state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:81 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:223 ACCEPT tcp -- <ACCESS_IP_2> <EXT_IP> state NEW tcp dpt:22 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:10000 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:10000 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:5901 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:5901 ACCEPT tcp -- <ACCESS_IP_1> <EXT_IP> state NEW tcp dpt:5900 ACCEPT tcp -- <ACCESS_IP_3> <EXT_IP> state NEW tcp dpt:5900 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-12 21:37 ` Tony Rogers @ 2011-04-14 20:24 ` Andrew Beverley 2011-04-15 13:21 ` Tony Rogers 0 siblings, 1 reply; 13+ messages in thread From: Andrew Beverley @ 2011-04-14 20:24 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter > Ok, trying with Thunderbird this time... (and it too seems to be > wrapping the text) <sigh> > Not sure about Thunderbird, but Evolution has a "preformat" option that doesn't wrap the text. Anyway, back to the original subject, can you post the output from "iptables-save" instead, as this has additional detail such as the interfaces in the rules. As a thought before you do so, if you're doing NAT in the normal way to share an internet connection, then what you are seeing is to be expected. You would normally SNAT on the internet-facing interface, not on the LAN-facing interface, meaning that traffic on the LAN interface will be going from/to public IP addresses. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-14 20:24 ` Andrew Beverley @ 2011-04-15 13:21 ` Tony Rogers 2011-04-15 15:29 ` Andrew Beverley 0 siblings, 1 reply; 13+ messages in thread From: Tony Rogers @ 2011-04-15 13:21 UTC (permalink / raw) To: Andrew Beverley; +Cc: netfilter On Thu, 2011-04-14 at 21:24 +0100, Andrew Beverley wrote: > > Ok, trying with Thunderbird this time... (and it too seems to be > > wrapping the text) <sigh> > > > > Not sure about Thunderbird, but Evolution has a "preformat" option that > doesn't wrap the text. > > Anyway, back to the original subject, can you post the output from > "iptables-save" instead, as this has additional detail such as the > interfaces in the rules. > > As a thought before you do so, if you're doing NAT in the normal way to > share an internet connection, then what you are seeing is to be > expected. You would normally SNAT on the internet-facing interface, not > on the LAN-facing interface, meaning that traffic on the LAN interface > will be going from/to public IP addresses. > > Andy > > > > ------------------------ > This email was scanned by BitDefender. Output of "iptables-save" below. *however* I *think* I may have solved it - I will know when I see the logs tomorrow morning. I changed my MASQ entry from MASQUERADE any to only MASQ my internal IP. (see last but two lines) Also - unless I misunderstand the rules - my SNAT is applied to the external interface? # Generated by iptables-save v1.3.5 on Fri Apr 15 14:07:02 2011 *filter :INPUT DROP [664:37461] :FORWARD DROP [334:41022] :OUTPUT ACCEPT [17005:1927625] :BADTCP - [0:0] :LOG_DROP - [0:0] :LOG_REJECT - [0:0] :NEWNOTSYN - [0:0] :PORTFWACCESS - [0:0] :PSCAN - [0:0] :XTACCESS - [0:0] -A INPUT -i eth1 -p tcp -m tcp --dport 1026:1028 -j DROP -A INPUT -i eth1 -p udp -m udp --dport 1026:1028 -j DROP -A INPUT -i eth1 -p udp -m udp --dport 67 -j DROP -A INPUT -i eth1 -p udp -m udp --dport 68 -j DROP -A INPUT -j BADTCP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -m state --state NEW -j ACCEPT -A INPUT -s 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP -A INPUT -d 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP -A INPUT -i eth0 -p ! icmp -m state --state NEW -j ACCEPT -A INPUT -m state --state NEW -j XTACCESS -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 5 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT -A INPUT -m limit --limit 10/min -j LOG --log-prefix "INPUT " -A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -p udp -j ACCEPT -A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -p igmp -j ACCEPT -A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -j DROP -A INPUT -s 224.0.0.0/240.0.0.0 -i eth1 -j DROP -A INPUT -s 240.0.0.0/240.0.0.0 -i eth1 -j DROP -A FORWARD -j BADTCP -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -m state --state NEW -j ACCEPT -A FORWARD -s 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP -A FORWARD -d 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP -A FORWARD -i eth0 -m state --state NEW -j ACCEPT -A FORWARD -m state --state NEW -j PORTFWACCESS -A FORWARD -m limit --limit 10/min -j LOG --log-prefix "OUTPUT " -A FORWARD -s $ACCESS_IP1 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 5060 -j ACCEPT -A FORWARD -s $ACCESS_IP1 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 1024:65535 -j ACCEPT -A FORWARD -s $ACCESS_NET1/255.255.255.240 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -s $ACCESS_IP2 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -s $ACCESS_IP3 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -s $ACCESS_IP2 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -s $ACCESS_NET1/255.255.255.240 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -s $ACCESS_IP3 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -s $ACCESS_IP3 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 20 -j ACCEPT -A FORWARD -s $ACCESS_IP3 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 21 -j ACCEPT -A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j PSCAN -A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j PSCAN -A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j PSCAN -A BADTCP -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j PSCAN -A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j PSCAN -A BADTCP -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j NEWNOTSYN -A LOG_DROP -m limit --limit 10/min -j LOG -A LOG_DROP -j DROP -A LOG_REJECT -m limit --limit 10/min -j LOG -A LOG_REJECT -j REJECT --reject-with icmp-port-unreachable -A NEWNOTSYN -m limit --limit 10/min -j LOG --log-prefix "NEW not SYN? " -A NEWNOTSYN -j DROP -A PSCAN -p tcp -m limit --limit 10/min -j LOG --log-prefix "TCP Scan? " -A PSCAN -p udp -m limit --limit 10/min -j LOG --log-prefix "UDP Scan? " -A PSCAN -p icmp -m limit --limit 10/min -j LOG --log-prefix "ICMP Scan? " -A PSCAN -f -m limit --limit 10/min -j LOG --log-prefix "FRAG Scan? " -A PSCAN -j DROP -A XTACCESS -d $EXT_IP -i eth1 -p tcp -m tcp --dport 20 -m state --state NEW -j ACCEPT -A XTACCESS -d $EXT_IP -i eth1 -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT -A XTACCESS -d $EXT_IP -i eth1 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT -A XTACCESS -s $ACCESS_IP4 -d $EXT_IP -i eth1 -p tcp -m tcp --dport 5000 -m state --state NEW -j ACCEPT -A XTACCESS -s $ACCESS_IP1 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 1024:65535 -j ACCEPT -A XTACCESS -s $ACCESS_IP1 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 5060 -j ACCEPT -A XTACCESS -s $ACCESS_IP2 -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A XTACCESS -s $ACCESS_IP3 -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A XTACCESS -s $ACCESS_IP2 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 223 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 81 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 223 -j ACCEPT -A XTACCESS -s $ACCESS_IP6 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A XTACCESS -s $ACCESS_IP2 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 10000 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 10000 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 5901 -j ACCEPT -A XTACCESS -s $ACCESS_IP2 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 5901 -j ACCEPT -A XTACCESS -s $ACCESS_IP5 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT -A XTACCESS -s $ACCESS_IP2 -d $EXT_IP -i eth1 -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT COMMIT # Completed on Fri Apr 15 14:07:02 2011 # Generated by iptables-save v1.3.5 on Fri Apr 15 14:07:02 2011 *mangle :PREROUTING ACCEPT [956876:478976939] :INPUT ACCEPT [18575:3467763] :FORWARD ACCEPT [938301:475509176] :OUTPUT ACCEPT [17013:1928657] :POSTROUTING ACCEPT [954894:477352925] :PORTFWMANGLE - [0:0] -A PREROUTING -j PORTFWMANGLE -A PREROUTING -d 224.0.0.1 -j DROP COMMIT # Completed on Fri Apr 15 14:07:02 2011 # Generated by iptables-save v1.3.5 on Fri Apr 15 14:07:02 2011 *nat :PREROUTING ACCEPT [18632:1718874] :POSTROUTING ACCEPT [6861:531454] :OUTPUT ACCEPT [6856:531214] -A PREROUTING -d $EXT_IP -i eth1 -p udp -m udp --dport 5060 -j DNAT --to-destination 192.168.0.2:5060 -A PREROUTING -d $EXT_IP -i eth1 -p udp -m udp --dport 1024:65535 -j DNAT --to-destination 192.168.0.2:1024-65535 -A PREROUTING -d $EXT_IP -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.2:80 -A PREROUTING -d $EXT_IP -i eth1 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.0.2:22 -A PREROUTING -d $EXT_IP -i eth1 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.0.2:20 -A PREROUTING -d $EXT_IP -i eth1 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.0.2:21 -A POSTROUTING -s 192.168.0.0/255.255.255.0 -m mark --mark 0x1 -j SNAT --to-source 192.168.0.1 -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o eth1 -j MASQUERADE COMMIT # Completed on Fri Apr 15 14:07:02 2011 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-15 13:21 ` Tony Rogers @ 2011-04-15 15:29 ` Andrew Beverley 2011-04-20 12:19 ` Tony Rogers 0 siblings, 1 reply; 13+ messages in thread From: Andrew Beverley @ 2011-04-15 15:29 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter > > Anyway, back to the original subject, can you post the output from > > "iptables-save" instead, as this has additional detail such as the > > interfaces in the rules. > > > > As a thought before you do so, if you're doing NAT in the normal way to > > share an internet connection, then what you are seeing is to be > > expected. You would normally SNAT on the internet-facing interface, not > > on the LAN-facing interface, meaning that traffic on the LAN interface > > will be going from/to public IP addresses. > > Output of "iptables-save" below. > > *however* > > I *think* I may have solved it - I will know when I see the logs tomorrow morning. > > I changed my MASQ entry from MASQUERADE any to only MASQ my internal > IP. (see last but two lines) > Ah, that would make sense. > Also - unless I misunderstand the rules - my SNAT is applied to the external interface? > <snip> > *nat > -A POSTROUTING -s 192.168.0.0/255.255.255.0 -m mark --mark 0x1 -j SNAT --to-source 192.168.0.1 Probably, yes, if all the clients on the internal network match the address range above, but if that's what you want then use -o $EXT_IF. Out of interest, why would you want to SNAT a public facing interface to a private IP address? > -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o eth1 -j MASQUERADE Are you sure you want MASQUERADE? If you're using a static IP address then you should use SNAT instead (see the man page). You can probably drop the "-s 192.168.0.0/255.255.255.0" as well. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-15 15:29 ` Andrew Beverley @ 2011-04-20 12:19 ` Tony Rogers 2011-04-20 19:41 ` Andrew Beverley 0 siblings, 1 reply; 13+ messages in thread From: Tony Rogers @ 2011-04-20 12:19 UTC (permalink / raw) To: Andrew Beverley; +Cc: netfilter On Fri, 2011-04-15 at 16:29 +0100, Andrew Beverley wrote: > > > Anyway, back to the original subject, can you post the output from > > > "iptables-save" instead, as this has additional detail such as the > > > interfaces in the rules. > > > > > > As a thought before you do so, if you're doing NAT in the normal way to > > > share an internet connection, then what you are seeing is to be > > > expected. You would normally SNAT on the internet-facing interface, not > > > on the LAN-facing interface, meaning that traffic on the LAN interface > > > will be going from/to public IP addresses. > > > > Output of "iptables-save" below. > > > > *however* > > > > I *think* I may have solved it - I will know when I see the logs tomorrow morning. > > > > I changed my MASQ entry from MASQUERADE any to only MASQ my internal > > IP. (see last but two lines) > > > > Ah, that would make sense. > > > Also - unless I misunderstand the rules - my SNAT is applied to the external interface? > > > > <snip> > > > *nat > > -A POSTROUTING -s 192.168.0.0/255.255.255.0 -m mark --mark 0x1 -j SNAT --to-source 192.168.0.1 > > Probably, yes, if all the clients on the internal network match the > address range above, but if that's what you want then use -o $EXT_IF. > > Out of interest, why would you want to SNAT a public facing interface to > a private IP address? > > > -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o eth1 -j MASQUERADE > > Are you sure you want MASQUERADE? If you're using a static IP address > then you should use SNAT instead (see the man page). You can probably > drop the "-s 192.168.0.0/255.255.255.0" as well. > > Andy > > > > ------------------------ > This email was scanned by BitDefender. Ok so I've re-checked all my rules, and tweaked them to use SNAT. Below is an example of the 'raw' log entry. If I'm interpreting this correctly: 212.118.226.91 is trying to connect to 192.168.0.168 ? Or is this some kind of reverse logic, and 192.168.0.168 is actually connecting to 212.118.226.91 on port 80? If so, why would the log entry be reversed? However, there is no rule that permits inbound connections of this nature. And (more worryingly) the connection appears to be sourced from eth0 (internal interface). Apr 20 11:21:52 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=115 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 Apr 20 11:21:59 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=116 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 Apr 20 11:22:04 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=117 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 Apr 20 11:22:23 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=118 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 Does this make sense to any of you gurus out there? Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iptables - external IP address on internal interface? 2011-04-20 12:19 ` Tony Rogers @ 2011-04-20 19:41 ` Andrew Beverley 0 siblings, 0 replies; 13+ messages in thread From: Andrew Beverley @ 2011-04-20 19:41 UTC (permalink / raw) To: Tony Rogers; +Cc: netfilter On Wed, 2011-04-20 at 13:19 +0100, Tony Rogers wrote: > If I'm interpreting this correctly: > > 212.118.226.91 is trying to connect to 192.168.0.168 ? > Not really "trying to connect", it's just a packet of data, so it could be the reply to a connection already initiated. > Or is this some kind of reverse logic, and 192.168.0.168 is actually > connecting to 212.118.226.91 on port 80? If so, why would the log > entry be reversed? I suspect that it is the *reply* packets. So your local client (.168) opens a connection to port 80 on the remote server (.91) and then the remote server sends a reply back which are the packets that you are seeing below. > However, there is no rule that permits inbound connections of this nature. > Well if you don't allow *any* packets in, then you will only have a one way connection, which is pretty useless... Are you sure you don't have a rule to allow ESTABLISHED connections back in? > And (more worryingly) the connection appears to be sourced from eth0 (internal interface). > I'd expect them to go OUT on the internal interface. Which chain are you logging the packets in? If it's POSTROUTING, then I'd expect IN to be blank - not sure why it is also eth0 - maybe your version of iptables. > > Apr 20 11:21:52 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=115 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 > Apr 20 11:21:59 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=116 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 > Apr 20 11:22:04 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=117 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 > Apr 20 11:22:23 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=118 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0 > > Does this make sense to any of you gurus out there? > Well I'm not a guru... but yes it does make sense, except for both the IN and OUT being the same. Try logging in the PREROUTING and FORWARD chains as well, and you should see the interfaces change. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-04-20 19:41 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-11 14:04 iptables - external IP address on internal interface? Tony Rogers
2011-04-11 14:42 ` Usuário do Sistema
2011-04-11 14:53 ` Jan Engelhardt
2011-04-11 17:52 ` Andrew Beverley
2011-04-12 9:20 ` Tony Rogers
2011-04-12 19:26 ` Andrew Beverley
2011-04-12 20:31 ` Robert Nichols
[not found] ` <1302626146.4938.1.camel@andybev-desktop>
[not found] ` <054F5B1BB94BD943B243C3B39B4F568D0161B8F7@victory.Erudine.local>
[not found] ` <1302636161.4938.5.camel@andybev-desktop>
2011-04-12 21:37 ` Tony Rogers
2011-04-14 20:24 ` Andrew Beverley
2011-04-15 13:21 ` Tony Rogers
2011-04-15 15:29 ` Andrew Beverley
2011-04-20 12:19 ` Tony Rogers
2011-04-20 19:41 ` Andrew Beverley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.