* 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
* 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.