Re: Natting html traffic

Re: Natting html traffic

[Bojan Sukalo]

Thank You Guido, maybe that's the way to go.

Regarding the masquerade I tried that also. Icmp is enabled and what
bothers me most it works even from inside to internet. (I can ping
www.google.com from inside - see the first post in thread).
I 'll try to install newer version of iptables. I hope that
dependencies won't bother me.
If I install newer version of iptables do I have to upgrade kernel or
I can just try and see whether the first update (only iptables) will
give results?



On Sat, Feb 13, 2010 at 5:06 PM, Guido Trentalancia
<guido@trentalancia.com> wrote:
> On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
>> I'am trying to setup nat on RHEL4 box.
>>
>> Kernel: Linux 2.6.9-89.ELsmp x86_64x86
>> iptables: 1.2.11
>
> Bojan,
>
> why don't you try to upgrade to a more recent version of iptables and if
> possible to a more recent kernel ? You know, just in case...
>
> I have a setup similar to yours (except from POSTROUTING which is of
> type MASQUERADING rather than SNAT) and it works all right.
>
> Also, have you checked other parameters such as TTL ? What about ICMP ?
> You can enable ICMP with the following rule:
>
> -A INPUT -p icmp -j ACCEPT
>
> Guido
>
>

Re: Natting html traffic

[Guido Trentalancia]

On Sat, 2010-02-13 at 17:46 +0100, Bojan Sukalo wrote:
> Thank You Guido, maybe that's the way to go.
> 
> Regarding the masquerade I tried that also. Icmp is enabled and what
> bothers me most it works even from inside to internet. (I can ping
> www.google.com from inside - see the first post in thread).

Oh yes, I did forget that.

> I 'll try to install newer version of iptables. I hope that
> dependencies won't bother me.

Try building it from scratch.

> If I install newer version of iptables do I have to upgrade kernel or
> I can just try and see whether the first update (only iptables) will
> give results?

The kernel is not that old. Most probably you won't necessarily need to
upgrade the kernel as it is 2.6.x. You can try building and installing
the latest iptables (version 1.4.6) and only after that a new kernel
(latest version is 2.6.32.8).

But before doing that, I would suggest you first try another ISP using a
dial-up connection to understand whether the TCP MSS diagnosis is
correct or not.

Good luck.

Guido

Re: Natting html traffic

[Bojan Sukalo]

First thing thank you both on your usefull remarks.


Guido wrote:

> The kernel is not that old. Most probably you won't necessarily need to
> upgrade the kernel as it is 2.6.x. You can try building and installing
> the latest iptables (version 1.4.6) and only after that a new kernel
> (latest version is 2.6.32.8).

> But before doing that, I would suggest you first try another ISP using a
> dial-up connection to understand whether the TCP MSS diagnosis is
> correct or not.

But also Mart said:

> Changing the iptables version will not change anything, if the current
> version does not have problems setting the kernel part correctly.
> You would need to upgrade kernel.

I suspect that Mark is right because iptables is just userspace app to
set netfilter kernel module but if that is not the case I could try
and install new version of iptables.

Mark:
> The rule-set looks okay for me.
> Does it only happen with google.com, or with all web hosts?

It's happenin for all types of tcp traffic from inside to internet.
Session established but nothing after that. No data traffic.

> Look how you have set the /proc/sys/net/ipv4/tcp_* options.

[root@natbox net]# grep -r '' ./ipv4 | grep tcp
./ipv4/netfilter/ip_conntrack_tcp_max_retrans:3
./ipv4/netfilter/ip_conntrack_tcp_be_liberal:0
./ipv4/netfilter/ip_conntrack_tcp_loose:3
./ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans:300
./ipv4/netfilter/ip_conntrack_tcp_timeout_close:10
./ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait:120
./ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack:30
./ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait:60
./ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait:120
./ipv4/netfilter/ip_conntrack_tcp_timeout_established:432000
./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv:60
./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent:120
./ipv4/tcp_slow_start_after_idle:1
./ipv4/tcp_workaround_signed_windows:1
./ipv4/tcp_bic_beta:819
./ipv4/tcp_tso_win_divisor:8
./ipv4/tcp_moderate_rcvbuf:1
./ipv4/tcp_bic_low_window:14
./ipv4/tcp_bic_fast_convergence:1
./ipv4/tcp_bic:1
./ipv4/tcp_vegas_gamma:2
./ipv4/tcp_vegas_beta:6
./ipv4/tcp_vegas_alpha:2
./ipv4/tcp_vegas_cong_avoid:0
./ipv4/tcp_westwood:0
./ipv4/tcp_no_metrics_save:0
./ipv4/tcp_low_latency:0
./ipv4/tcp_frto:0
./ipv4/tcp_tw_reuse:0
./ipv4/tcp_adv_win_scale:2
./ipv4/tcp_app_win:31
./ipv4/tcp_rmem:4096	87380	174760
./ipv4/tcp_wmem:4096	16384	131072
./ipv4/tcp_mem:786432	1048576	1572864
./ipv4/tcp_dsack:1
./ipv4/tcp_ecn:0
./ipv4/tcp_reordering:3
./ipv4/tcp_fack:1
./ipv4/tcp_orphan_retries:0
./ipv4/tcp_max_syn_backlog:1024
./ipv4/tcp_rfc1337:0
./ipv4/tcp_stdurg:0
./ipv4/tcp_abort_on_overflow:0
./ipv4/tcp_tw_recycle:0
./ipv4/tcp_syncookies:0
./ipv4/tcp_fin_timeout:60
./ipv4/tcp_retries2:15
./ipv4/tcp_retries1:3
./ipv4/tcp_keepalive_intvl:75
./ipv4/tcp_keepalive_probes:9
./ipv4/tcp_keepalive_time:7200
./ipv4/tcp_max_tw_buckets:180000
./ipv4/tcp_max_orphans:262144
./ipv4/tcp_synack_retries:5
./ipv4/tcp_syn_retries:5
./ipv4/tcp_retrans_collapse:1
./ipv4/tcp_sack:1
./ipv4/tcp_window_scaling:1
./ipv4/tcp_timestamps:1

Please if you can find any strange things in this setup let me know

Bojan

Re: Natting html traffic

[Guido Trentalancia]

On Sun, 2010-02-14 at 11:52 +0100, Bojan Sukalo wrote:
> First thing thank you both on your usefull remarks.
> 
> 
> Guido wrote:
> 
> > The kernel is not that old. Most probably you won't necessarily need to
> > upgrade the kernel as it is 2.6.x. You can try building and installing
> > the latest iptables (version 1.4.6) and only after that a new kernel
> > (latest version is 2.6.32.8).
> 
> > But before doing that, I would suggest you first try another ISP using a
> > dial-up connection to understand whether the TCP MSS diagnosis is
> > correct or not.
> 
> But also Mart said:
> 
> > Changing the iptables version will not change anything, if the current
> > version does not have problems setting the kernel part correctly.
> > You would need to upgrade kernel.
> 
> I suspect that Mark is right because iptables is just userspace app to
> set netfilter kernel module but if that is not the case I could try
> and install new version of iptables.
> 
> Mark:
> > The rule-set looks okay for me.
> > Does it only happen with google.com, or with all web hosts?
> 
> It's happenin for all types of tcp traffic from inside to internet.
> Session established but nothing after that. No data traffic.
> 
> > Look how you have set the /proc/sys/net/ipv4/tcp_* options.
> 
> [root@natbox net]# grep -r '' ./ipv4 | grep tcp
> ./ipv4/netfilter/ip_conntrack_tcp_max_retrans:3
> ./ipv4/netfilter/ip_conntrack_tcp_be_liberal:0
> ./ipv4/netfilter/ip_conntrack_tcp_loose:3
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans:300
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_close:10
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait:120
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack:30
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait:60
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait:120
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_established:432000
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv:60
> ./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent:120
> ./ipv4/tcp_slow_start_after_idle:1
> ./ipv4/tcp_workaround_signed_windows:1
> ./ipv4/tcp_bic_beta:819
> ./ipv4/tcp_tso_win_divisor:8
> ./ipv4/tcp_moderate_rcvbuf:1
> ./ipv4/tcp_bic_low_window:14
> ./ipv4/tcp_bic_fast_convergence:1
> ./ipv4/tcp_bic:1
> ./ipv4/tcp_vegas_gamma:2
> ./ipv4/tcp_vegas_beta:6
> ./ipv4/tcp_vegas_alpha:2
> ./ipv4/tcp_vegas_cong_avoid:0
> ./ipv4/tcp_westwood:0
> ./ipv4/tcp_no_metrics_save:0
> ./ipv4/tcp_low_latency:0
> ./ipv4/tcp_frto:0
> ./ipv4/tcp_tw_reuse:0
> ./ipv4/tcp_adv_win_scale:2
> ./ipv4/tcp_app_win:31
> ./ipv4/tcp_rmem:4096	87380	174760
> ./ipv4/tcp_wmem:4096	16384	131072
> ./ipv4/tcp_mem:786432	1048576	1572864
> ./ipv4/tcp_dsack:1
> ./ipv4/tcp_ecn:0
> ./ipv4/tcp_reordering:3
> ./ipv4/tcp_fack:1
> ./ipv4/tcp_orphan_retries:0
> ./ipv4/tcp_max_syn_backlog:1024
> ./ipv4/tcp_rfc1337:0
> ./ipv4/tcp_stdurg:0
> ./ipv4/tcp_abort_on_overflow:0
> ./ipv4/tcp_tw_recycle:0
> ./ipv4/tcp_syncookies:0
> ./ipv4/tcp_fin_timeout:60
> ./ipv4/tcp_retries2:15
> ./ipv4/tcp_retries1:3
> ./ipv4/tcp_keepalive_intvl:75
> ./ipv4/tcp_keepalive_probes:9
> ./ipv4/tcp_keepalive_time:7200
> ./ipv4/tcp_max_tw_buckets:180000
> ./ipv4/tcp_max_orphans:262144
> ./ipv4/tcp_synack_retries:5
> ./ipv4/tcp_syn_retries:5
> ./ipv4/tcp_retrans_collapse:1
> ./ipv4/tcp_sack:1
> ./ipv4/tcp_window_scaling:1
> ./ipv4/tcp_timestamps:1
> 
> Please if you can find any strange things in this setup let me know
> 
> Bojan
> --
> 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

Some parameters are non-default at least according to more recent
kernels, for example:

./ipv4/tcp_workaround_signed_windows:0
./ipv4/tcp_tso_win_divisor:3
./ipv4/tcp_frto:2
./ipv4/tcp_ecn:2
./ipv4/tcp_max_orphans:16384

But you could have already rebuilt kernel and iptables in this time...
And have you tried another ISP ? The latter is a very important test.

Guido

Re: Natting html traffic

[Mart Frauenlob]

On 13.02.2010 17:06, netfilter-owner@vger.kernel.org wrote:
> On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
>> I'am trying to setup nat on RHEL4 box.
>>
>> Kernel: Linux 2.6.9-89.ELsmp x86_64x86
>> iptables: 1.2.11
> 
> Bojan,
> 
> why don't you try to upgrade to a more recent version of iptables and if
> possible to a more recent kernel ? You know, just in case...

Changing the iptables version will not change anything, if the current
version does not have problems setting the kernel part correctly.
You would need to upgrade kernel.

> 
> I have a setup similar to yours (except from POSTROUTING which is of
> type MASQUERADING rather than SNAT) and it works all right.
> 
> Also, have you checked other parameters such as TTL ? What about ICMP ?
> You can enable ICMP with the following rule:
> 
> -A INPUT -p icmp -j ACCEPT

what should allowing INPUT icmp help in a case where there's a FORWARD
rule? He allows ESTABLISHED,RELATED traffic, that should allow icmp
messages that result from tcp errors.

Best regards

Mart

Re: Natting html traffic

[Mart Frauenlob]

On 13.02.2010 15:47, netfilter-owner@vger.kernel.org wrote:
> Hello again !
> 
> On Sat, 2010-02-13 at 13:22 +0100, Bojan Sukalo wrote:
>> OK, just not to go off topic here (telnet can be used to comunicate
>> with lots of stuff)
>>
>> Here are my iptables rules with comments.
>>
>> iptables -P INPUT DROP
>> iptables -P FORWARD DROP
>> iptables -P OUTPUT ACCEPT
>>
>> iptables -F INPUT
>> iptables -F FORWARD
>> iptables -F OUTPUT
>> iptables -F -t nat
>>
>> ##from internal to outside world
>> iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
>>
>> ##from vpn clients to inisde
>> iptables -A FORWARD -i tap0 -o eth1 -j ACCEPT
>>
>>
>> ##established sessions from outside to inside
>> iptables -A FORWARD -i eth0 -o eth1 -m state --state
>> ESTABLISHED,RELATED -j ACCEPT
>> ## established session from inside to vpn clients
>> iptables -A FORWARD -i eth1 -o tap0 -m state --state
>> ESTABLISHED,RELATED -j ACCEPT
>>
>> ##Allow inputs from the internal network and local interfaces
>> iptables -A INPUT -i eth1 -s 192.168.60.0/24 -d 0/0 -j ACCEPT
>> iptables -A INPUT -i tap0 -s 192.168.168.0/24 -d 0/0 -j ACCEPT
>> iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
> 

you really don't need those -s 0/0 -d 0/0 address descriptors, just
waste of time writing them.

> The last three entries are not very secure. In particular, the first two
> leave all ports open, while in a real situation you'd better have an
> entry for each allowed service/port (by adding "-m state --state NEW -m
> tcp -p tcp --dport ALLOWED_SERVICE_PORT", substituting
> ALLOWED_SERVICE_PORT with the service you need and perhaps removing -d
> 0/0).
> 

In real life it's very often the case to allow all state NEW (in NAT
case traffic must be valid for the conntrack engine - state NEW might
not even be required) traffic going out the LAN. Depends on the
conditions to be more or less restrictive.

> You could also add for the loopback interface this entry (although it
> should be equivalent to setting rp_filter=1):
> 
> -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
> 
>> ## NAT to public source ip (also tried -j MASQUARADE here but that
>> also didn't help)
>> iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j SNAT
>> --to-source my_public_ip
> 
> iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j MASQUERADE
> 
> because amongst other things, if you use SNAT then you would also need
> DNAT !
> 
> And remember to do "echo 1 > /proc/sys/net/ipv4/ip_forward" to enable
> forwarding.
> 
>> ##prevent some spoofing from outside
>> iptables -A INPUT -i eth0 -s 192.168.60.0/24 -j DROP
>> iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
> 
> I think you could just use:
> 
> echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
> 
> or just a similar command for specific interfaces.
> 

if one uses ESTABLISHED,RELATED state match for back-in coming traffic,
how could a spoofed packet have a valid conntrack entry?
hence those anti spoofing rules are not needed, nor is the rp_filter
setting for this interface.

[...]

Best regards

Mart

Re: Natting html traffic

[Mart Frauenlob]

On 13.02.2010 00:03, netfilter-owner@vger.kernel.org wrote:
> I'am trying to setup nat on RHEL4 box.
> 
> Kernel: Linux 2.6.9-89.ELsmp x86_64x86
> iptables: 1.2.11
> 
> I have static public ip address on eth0 and 192.168.60.1 address on
> privat LAN (eth1)
> 
> Also I have tap0 (192.168.168.1) interface enabled and working openvpn
> connection to all hosts in privat LAN (including NAT box)
> 
> I have done this numerous times before. Never the less, I have problem
> now and I am stuck.
> 
> Current situation is this:
> 
> Working ping to www.google.com from servers inside. Also working ping
> with -s 1472 with don't fragment set  (full size packet).
> 
> Telnet from inside machine to www.google.com 80 works but I can't get
> any messages after I get connected (Just successfull telnet
> connection)
> 
> Accessing web from nat box is ok.
> 
> I have tried to sniff traffic and I have seen ACK, SYN ACK, ACK
> packets when trying to hit www.google.com from inside. After that I
> have IP bad-len: 0 messages (When I see inside them, these look like
> packets from google with HTML tags but something is wrong with them)
> 
> I found that this can be tcpmss problem and done --clamp-mss-to-mtu
> stuff but that didn't work either.
> Also tried setting mss to low value (250), just in case. Didn't help either.
> 
> What is the problem here? I dont see bugs on iptables version 1.2.11
> that can have this kind of impact on traffic.
> 
> These are my iptables rules
> 
> Quote:
> [root@natbox]# iptables -nvL
> Chain INPUT (policy DROP 1729 packets, 105K bytes)
> pkts bytes target prot opt in out source destination
> 611K 239M ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> 8311 795K ACCEPT all -- eth1 * 192.168.60.0/24 0.0.0.0/0
> 30548 2963K ACCEPT all -- tap0 * 192.168.168.0/24 0.0.0.0/0
> 48001 9271K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 0 0 DROP all -- eth0 * 192.168.60.0/24 0.0.0.0/0
> 0 0 DROP all -- eth0 * 127.0.0.0/8 0.0.0.0/0
> 0 0 ACCEPT tcp -- eth0 * allowed_ssh_ip 0.0.0.0/0 tcp dpt:22
> 149 6297 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
> 0 0 ACCEPT udp -- * * my_dns_server 0.0.0.0/0 udp spt:53
> 
> Chain FORWARD (policy DROP 28 packets, 1120 bytes)
> pkts bytes target prot opt in out source destination
> 4741 472K ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
> 398K 177M ACCEPT all -- tap0 eth1 0.0.0.0/0 0.0.0.0/0
> 135 20160 ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> 273K 87M ACCEPT all -- eth1 tap0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> 
> Chain OUTPUT (policy ACCEPT 544K packets, 139M bytes)
> pkts bytes target prot opt in out source destination
> 
> [root@natbox]# iptables -nvL -t nat
> Chain PREROUTING (policy ACCEPT 18221 packets, 1683K bytes)
> pkts bytes target prot opt in out source destination
> 
> Chain POSTROUTING (policy ACCEPT 19019 packets, 1435K bytes)
> pkts bytes target prot opt in out source destination
> 3612 203K SNAT all -- * eth0 192.168.60.0/24 0.0.0.0/0
> to:my_public_ip
> Chain OUTPUT (policy ACCEPT 18070 packets, 1389K bytes)
> pkts bytes target prot opt in out source destination
> 
> [root@natbox]# iptables -nvL -t mangle
> Chain PREROUTING (policy ACCEPT 96895 packets, 30M bytes)
> pkts bytes target prot opt in out source destination
> 
> Chain INPUT (policy ACCEPT 67263 packets, 18M bytes)
> pkts bytes target prot opt in out source destination
> 
> Chain FORWARD (policy ACCEPT 29470 packets, 12M bytes)
> pkts bytes target prot opt in out source destination
> 15 900 TCPMSS tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02
> TCPMSS clamp to PMTU
> 
> Chain OUTPUT (policy ACCEPT 60095 packets, 15M bytes)
> pkts bytes target prot opt in out source destination
> 
> Chain POSTROUTING (policy ACCEPT 90014 packets, 27M bytes)
> pkts bytes target prot opt in out source destination
> 

The rule-set looks okay for me.
Does it only happen with google.com, or with all web hosts?

I've seen issues like that on this list, where MSS, or tcp options been
the cause for mysterious connection hanging.
Look how you have set the /proc/sys/net/ipv4/tcp_* options.
Especially tcp_sack, tcp_dsack, tcp_ecn. There's a lot of options there
and they may differ depending on kernel version and distro patchlevel.
Try to disable 'special' options.
Post what could be relevant, if trying does not help.

Also you could try to place a log rule before the filter table FORWARD
chain policy hits. Maybe packets get dropped for some reason i.e.
INVALID state (as you don't log/drop them in your rule-set).

Best regards

Mart

Re: Natting html traffic

[Guido Trentalancia]

Hello again !

On Sat, 2010-02-13 at 16:29 +0100, Bojan Sukalo wrote:
> >> iptables -t mangle -A FORWARD -i eth1 -o eth0 -p tcp --tcp-flags
> >> SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
> >
> > What do you want to achieve with the last rule ?
> 
> I tried to set mss in my last rule because this type of problem
> (acording to iptables man page) can happen because of bigger mss
> values and fragmenting packets after that.
> When I say this type of problem I mean "established tcp session but no
> traffic after that"

Well, in the manual page it mentions about "criminally braindead ISPs or
servers". So, to make sure that is the cause, you could try the existing
setup with another ISP using one of the many free dial-up connections
that are generally available.

If the problem persists with other ISPs, then at least you know it might
be a different cause perhaps something to do with your setup.

Regards,

Guido

Re: Natting html traffic

[Guido Trentalancia]

On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
> I'am trying to setup nat on RHEL4 box.
> 
> Kernel: Linux 2.6.9-89.ELsmp x86_64x86
> iptables: 1.2.11

Bojan,

why don't you try to upgrade to a more recent version of iptables and if
possible to a more recent kernel ? You know, just in case...

I have a setup similar to yours (except from POSTROUTING which is of
type MASQUERADING rather than SNAT) and it works all right.

Also, have you checked other parameters such as TTL ? What about ICMP ?
You can enable ICMP with the following rule:

-A INPUT -p icmp -j ACCEPT

Guido

Re: Natting html traffic

[Bojan Sukalo]

Hello Guido,

> The last three entries are not very secure. In particular, the first two
> leave all ports open, while in a real situation you'd better have an
> entry for each allowed service/port (by adding "-m state --state NEW -m
> tcp -p tcp --dport ALLOWED_SERVICE_PORT", substituting
> ALLOWED_SERVICE_PORT with the service you need and perhaps removing -d
> 0/0).

I know that my rules are not the best regarding the security and I
will take care about that when I have basic functionality. That is, in
theory when I apply the rules we are talking about I should have
proper http traffic from inside to the internet. That's just not
happening here.

> And remember to do "echo 1 > /proc/sys/net/ipv4/ip_forward" to enable
> forwarding.

I have ipforwarding enabled. (Remember, I have working opnvpn
connection going from tap0 interface to eth1)
The only thing I dont have is tcp traffic from inside to internet.


>> iptables -t mangle -A FORWARD -i eth1 -o eth0 -p tcp --tcp-flags
>> SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
>
> What do you want to achieve with the last rule ?

I tried to set mss in my last rule because this type of problem
(acording to iptables man page) can happen because of bigger mss
values and fragmenting packets after that.
When I say this type of problem I mean "established tcp session but no
traffic after that"

> iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j MASQUERADE
>
> because amongst other things, if you use SNAT then you would also need
> DNAT !

I have used -j SNAT because it's recomended way in iptables man page
when you have static ip address on outside interface. -j DNAT is used
when you want to portforward inside.

Bojan

Re: Natting html traffic

[Guido Trentalancia]

Hello again !

On Sat, 2010-02-13 at 13:22 +0100, Bojan Sukalo wrote:
> OK, just not to go off topic here (telnet can be used to comunicate
> with lots of stuff)
> 
> Here are my iptables rules with comments.
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
> 
> iptables -F INPUT
> iptables -F FORWARD
> iptables -F OUTPUT
> iptables -F -t nat
> 
> ##from internal to outside world
> iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> 
> ##from vpn clients to inisde
> iptables -A FORWARD -i tap0 -o eth1 -j ACCEPT
> 
> 
> ##established sessions from outside to inside
> iptables -A FORWARD -i eth0 -o eth1 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> ## established session from inside to vpn clients
> iptables -A FORWARD -i eth1 -o tap0 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> 
> ##Allow inputs from the internal network and local interfaces
> iptables -A INPUT -i eth1 -s 192.168.60.0/24 -d 0/0 -j ACCEPT
> iptables -A INPUT -i tap0 -s 192.168.168.0/24 -d 0/0 -j ACCEPT
> iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

The last three entries are not very secure. In particular, the first two
leave all ports open, while in a real situation you'd better have an
entry for each allowed service/port (by adding "-m state --state NEW -m
tcp -p tcp --dport ALLOWED_SERVICE_PORT", substituting
ALLOWED_SERVICE_PORT with the service you need and perhaps removing -d
0/0).

You could also add for the loopback interface this entry (although it
should be equivalent to setting rp_filter=1):

-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

> ## NAT to public source ip (also tried -j MASQUARADE here but that
> also didn't help)
> iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j SNAT
> --to-source my_public_ip

iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j MASQUERADE

because amongst other things, if you use SNAT then you would also need
DNAT !

And remember to do "echo 1 > /proc/sys/net/ipv4/ip_forward" to enable
forwarding.

> ##prevent some spoofing from outside
> iptables -A INPUT -i eth0 -s 192.168.60.0/24 -j DROP
> iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

I think you could just use:

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

or just a similar command for specific interfaces.

> ##add some access rules for ssh and openvpn
> iptables -A INPUT -i eth0 -p tcp -s ssh_allowed_public_ip
> --destination-port 22 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp -s 0/0 --destination-port 1194 -j ACCEPT
>
> ##giving trust to my public dns, just in case
> iptables -A INPUT -p udp -s my_public_dns --source-port 53 -d 0/0 -j ACCEPT
> 
> ##trying hard nat to work by clamping mss to mtu
> iptables -t mangle -A FORWARD -i eth1 -o eth0 -p tcp --tcp-flags
> SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

What do you want to achieve with the last rule ?

Regards,

Guido

Re: Natting html traffic

[Bojan Sukalo]

2010/2/13 Oskar Berggren <oskar.berggren@gmail.com>:
> 2010/2/13 Покотиленко Костик <casper@meteor.dp.ua>:
>> В Суб, 13/02/2010 в 00:18 +0100, Guido Trentalancia пишет:
>>> On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
>>> > Telnet from inside machine to www.google.com 80 works but I can't get
>>> > any messages after I get connected (Just successfull telnet
>>> > connection)
>>>
>>> You can't telnet www.google.com on port 80, as google is not a telnet
>>> server and therefore it can't deal with the telnet protocol. Google
>>> deals with the http protocol.
>>
>> Why one can't use telnet program to test http server?
>>
>
>
> Sure you can. Of course you need to type in a valid HTTP request to
> get a response. This worked for me just now:
>
> ~$ telnet www.google.com 80
> Trying 74.125.79.104...
> Connected to www.l.google.com.
> Escape character is '^]'.
>
> Then I typed this, followed by enter twice:
> GET http://www.google.se/ HTTP/1.1
>
> And I got this reply from the server:
> HTTP/1.1 200 OK
> Date: Sat, 13 Feb 2010 09:51:26 GMT
> Expires: -1
> Cache-Control: private, max-age=0
> Content-Type: text/h_t_m_l; charset=ISO-8859-1
> [... plus lots more, shortened...]
>
>
> By the way, I had to mangle the content type above to fool the vger
> spam filter, which seems to think that my message contains HTML
> because of the line, even though any reasonable MIME parser should
> realize that line is part of a text/plain content, and not a header
> for a new section.
>
> /Oskar
>

OK, just not to go off topic here (telnet can be used to comunicate
with lots of stuff)

Here are my iptables rules with comments.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

##from internal to outside world
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

##from vpn clients to inisde
iptables -A FORWARD -i tap0 -o eth1 -j ACCEPT


##established sessions from outside to inside
iptables -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
## established session from inside to vpn clients
iptables -A FORWARD -i eth1 -o tap0 -m state --state
ESTABLISHED,RELATED -j ACCEPT

##Allow inputs from the internal network and local interfaces
iptables -A INPUT -i eth1 -s 192.168.60.0/24 -d 0/0 -j ACCEPT
iptables -A INPUT -i tap0 -s 192.168.168.0/24 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

## NAT to public source ip (also tried -j MASQUARADE here but that
also didn't help)
iptables -A POSTROUTING -t nat -s 192.168.60.0/24 -o eth0 -j SNAT
--to-source my_public_ip

##prevent some spoofing from outside
iptables -A INPUT -i eth0 -s 192.168.60.0/24 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

##add some access rules for ssh and openvpn
iptables -A INPUT -i eth0 -p tcp -s ssh_allowed_public_ip
--destination-port 22 -j ACCEPT
iptables -A INPUT -i eth0 -p udp -s 0/0 --destination-port 1194 -j ACCEPT

##giving trust to my public dns, just in case
iptables -A INPUT -p udp -s my_public_dns --source-port 53 -d 0/0 -j ACCEPT

##trying hard nat to work by clamping mss to mtu
iptables -t mangle -A FORWARD -i eth1 -o eth0 -p tcp --tcp-flags
SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Re: Natting html traffic

[Oskar Berggren]

2010/2/13 Покотиленко Костик <casper@meteor.dp.ua>:
> В Суб, 13/02/2010 в 00:18 +0100, Guido Trentalancia пишет:
>> On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
>> > Telnet from inside machine to www.google.com 80 works but I can't get
>> > any messages after I get connected (Just successfull telnet
>> > connection)
>>
>> You can't telnet www.google.com on port 80, as google is not a telnet
>> server and therefore it can't deal with the telnet protocol. Google
>> deals with the http protocol.
>
> Why one can't use telnet program to test http server?
>


Sure you can. Of course you need to type in a valid HTTP request to
get a response. This worked for me just now:

~$ telnet www.google.com 80
Trying 74.125.79.104...
Connected to www.l.google.com.
Escape character is '^]'.

Then I typed this, followed by enter twice:
GET http://www.google.se/ HTTP/1.1

And I got this reply from the server:
HTTP/1.1 200 OK
Date: Sat, 13 Feb 2010 09:51:26 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/h_t_m_l; charset=ISO-8859-1
[... plus lots more, shortened...]


By the way, I had to mangle the content type above to fool the vger
spam filter, which seems to think that my message contains HTML
because of the line, even though any reasonable MIME parser should
realize that line is part of a text/plain content, and not a header
for a new section.

/Oskar

Re: Natting html traffic

[Peter Chacko]

but if telnetd is not started on http server or configured to ignore
telnet stream, you will just get a connection time out on client....
so its not a good idea to prob http server with telnet protocol.

Peter chacko.

2010/2/13 Guido Trentalancia <guido@trentalancia.com>:
> On Sat, 2010-02-13 at 04:13 +0200, Покотиленко Костик wrote:
>> В Суб, 13/02/2010 в 00:18 +0100, Guido Trentalancia пишет:
>> > On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
>> > > Telnet from inside machine to www.google.com 80 works but I can't get
>> > > any messages after I get connected (Just successfull telnet
>> > > connection)
>> >
>> > You can't telnet www.google.com on port 80, as google is not a telnet
>> > server and therefore it can't deal with the telnet protocol. Google
>> > deals with the http protocol.
>>
>> Why one can't use telnet program to test http server?
>
> Just because one won't get anything more than just "connected". So it is
> not a very useful way to test HTTP nor NAT...
>
> Guido
>
> --
> 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
>

Re: Natting html traffic

[Guido Trentalancia]

On Sat, 2010-02-13 at 04:13 +0200, Покотиленко Костик wrote:
> В Суб, 13/02/2010 в 00:18 +0100, Guido Trentalancia пишет:
> > On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
> > > Telnet from inside machine to www.google.com 80 works but I can't get
> > > any messages after I get connected (Just successfull telnet
> > > connection)
> > 
> > You can't telnet www.google.com on port 80, as google is not a telnet
> > server and therefore it can't deal with the telnet protocol. Google
> > deals with the http protocol.
> 
> Why one can't use telnet program to test http server?

Just because one won't get anything more than just "connected". So it is
not a very useful way to test HTTP nor NAT...

Guido

Re: Natting html traffic

[Покотиленко Костик]

В Суб, 13/02/2010 в 00:18 +0100, Guido Trentalancia пишет:
> On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
> > Telnet from inside machine to www.google.com 80 works but I can't get
> > any messages after I get connected (Just successfull telnet
> > connection)
> 
> You can't telnet www.google.com on port 80, as google is not a telnet
> server and therefore it can't deal with the telnet protocol. Google
> deals with the http protocol.

Why one can't use telnet program to test http server?

> If you can use your web browser then you are fine, it means NAT is
> working.
> 
> You could try telnet or other TCP/IP protocols but you need appropriate
> servers for them.
> 
> If you want to try telnet and you don't know any telnet server, you
> could try telnet on port 25 to your smtp mail server. At least you can
> have a basic dialogue with it (refer to the smtp protocol, there are
> HELO, MAIL, QUIT and other commands that you can issue).
> 
> I hope it helps.
> 
> Bye,
> 
> Guido
> 
> --
> 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
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: Natting html traffic

[Guido Trentalancia]

On Sat, 2010-02-13 at 00:03 +0100, Bojan Sukalo wrote:
> Telnet from inside machine to www.google.com 80 works but I can't get
> any messages after I get connected (Just successfull telnet
> connection)

You can't telnet www.google.com on port 80, as google is not a telnet
server and therefore it can't deal with the telnet protocol. Google
deals with the http protocol.

If you can use your web browser then you are fine, it means NAT is
working.

You could try telnet or other TCP/IP protocols but you need appropriate
servers for them.

If you want to try telnet and you don't know any telnet server, you
could try telnet on port 25 to your smtp mail server. At least you can
have a basic dialogue with it (refer to the smtp protocol, there are
HELO, MAIL, QUIT and other commands that you can issue).

I hope it helps.

Bye,

Guido

Natting html traffic

[Bojan Sukalo]

I'am trying to setup nat on RHEL4 box.

Kernel: Linux 2.6.9-89.ELsmp x86_64x86
iptables: 1.2.11

I have static public ip address on eth0 and 192.168.60.1 address on
privat LAN (eth1)

Also I have tap0 (192.168.168.1) interface enabled and working openvpn
connection to all hosts in privat LAN (including NAT box)

I have done this numerous times before. Never the less, I have problem
now and I am stuck.

Current situation is this:

Working ping to www.google.com from servers inside. Also working ping
with -s 1472 with don't fragment set  (full size packet).

Telnet from inside machine to www.google.com 80 works but I can't get
any messages after I get connected (Just successfull telnet
connection)

Accessing web from nat box is ok.

I have tried to sniff traffic and I have seen ACK, SYN ACK, ACK
packets when trying to hit www.google.com from inside. After that I
have IP bad-len: 0 messages (When I see inside them, these look like
packets from google with HTML tags but something is wrong with them)

I found that this can be tcpmss problem and done --clamp-mss-to-mtu
stuff but that didn't work either.
Also tried setting mss to low value (250), just in case. Didn't help either.

What is the problem here? I dont see bugs on iptables version 1.2.11
that can have this kind of impact on traffic.

These are my iptables rules

Quote:
[root@natbox]# iptables -nvL
Chain INPUT (policy DROP 1729 packets, 105K bytes)
pkts bytes target prot opt in out source destination
611K 239M ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
8311 795K ACCEPT all -- eth1 * 192.168.60.0/24 0.0.0.0/0
30548 2963K ACCEPT all -- tap0 * 192.168.168.0/24 0.0.0.0/0
48001 9271K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- eth0 * 192.168.60.0/24 0.0.0.0/0
0 0 DROP all -- eth0 * 127.0.0.0/8 0.0.0.0/0
0 0 ACCEPT tcp -- eth0 * allowed_ssh_ip 0.0.0.0/0 tcp dpt:22
149 6297 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 ACCEPT udp -- * * my_dns_server 0.0.0.0/0 udp spt:53

Chain FORWARD (policy DROP 28 packets, 1120 bytes)
pkts bytes target prot opt in out source destination
4741 472K ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
398K 177M ACCEPT all -- tap0 eth1 0.0.0.0/0 0.0.0.0/0
135 20160 ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
273K 87M ACCEPT all -- eth1 tap0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 544K packets, 139M bytes)
pkts bytes target prot opt in out source destination

[root@natbox]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 18221 packets, 1683K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 19019 packets, 1435K bytes)
pkts bytes target prot opt in out source destination
3612 203K SNAT all -- * eth0 192.168.60.0/24 0.0.0.0/0
to:my_public_ip
Chain OUTPUT (policy ACCEPT 18070 packets, 1389K bytes)
pkts bytes target prot opt in out source destination

[root@natbox]# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 96895 packets, 30M bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 67263 packets, 18M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 29470 packets, 12M bytes)
pkts bytes target prot opt in out source destination
15 900 TCPMSS tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02
TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT 60095 packets, 15M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 90014 packets, 27M bytes)
pkts bytes target prot opt in out source destination

Thank You