Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Short version: Are there any special settings for NAT to work correctly on Linux' virtual network interfaces?

I am running a Linux (2.6.39-2-486 Debian build) box as NAT server. It has a real network interface eth0, which connects to the outside, and a virtual one eth0:0 with address 192.168.42.2 and netmask /24 to an inside network. Several computers inside connect to the internet via this box (having their default gateway set to 192.168.42.2), which has its firewall set up as (default forward policy set for debugging purposes):

iptables -F
iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.42.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.42.0/24 -j ACCEPT
iptables -t nat -F
iptables -t nat -A POSTROUTING -s 192.168.42.0/24 '!' -d 192.168.42.0/24 -j MASQUERADE

Most of the times, this setup works just fine. SSH, HTTP, other traffic works. However, connections to some SSL-secured sites will block indefinitely after connecting, even though the connection works when trying to run wget directly from the server. Other SSL-sites work just fine, however. Example:

client:~> wget -dv https://use.typekit.com/qqh6jah.js
Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.12 on linux-gnu.

--2011-07-24 15:59:14--  https://use.typekit.com/qqh6jah.js
Resolving use.typekit.com... 68.232.35.119
Caching use.typekit.com => 68.232.35.119
Connecting to use.typekit.com|68.232.35.119|:443... connected.
Created socket 3.
Releasing 0x08ccd160 (new refcount 1).
Initiating SSL handshake.

Any idea what is going on here? I have played around with different -j LOG settings, but lack the enlightenment to select the right logging to see what's going wrong.

share|improve this question

migrated from stackoverflow.com Jul 24 '11 at 14:33

This question came from our site for professional and enthusiast programmers.

1 Answer 1

The best would be to get a tcpdump of the issue on the NAT box eth0 interface, that would be useful to see if the DNAT rules acts as expected. Also, mangle/raw table are empty, right?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.