Hello Everyone; I have a weird issue that I'm running into that I could use some help on. I have a Linux firewall/router on the edge of my home network which has a PPPoE connection to my service provider. This router is a Linux VM on a Linux host, utilizing libvirt/qemu/kvm. All of my network interfaces used for routing are bridged to bridge interfaces on the host VM. eth1 on my firewall/router is where my LAN hosts live, this bridges into an Ethernet switched broadcast domain. It's subnet is 192.168.0.0/25. ppp1 on my firewall/router is the interface that is being used for inbound/outbound packets for my LAN. It has an IP address assigned by IPCP via PPP. I have a router behind eth1 that is being used for some VoIP access. It has an gig 0/1 interface that belongs to the eth1 subnet, and a eth 0/1 interface that belongs to a separate network 192.168.99.0/24. This router is an Adtran box and is not running on any VMs. I am using IP MASQUERADING to allow my LAN hosts to access my PPPoE connection. Here is the relevant configuration: joel@router:~$ sudo iptables -t nat -nvL <SNIP>...</SNIP> Chain POSTROUTING (policy ACCEPT 663 packets, 55361 bytes) pkts bytes target prot opt in out source destination 393K 27M MASQUERADE all -- * ppp1 192.168.0.0/24 0.0.0.0/0 4844 236K MASQUERADE all -- * ppp1 192.168.99.0/24 0.0.0.0/0 I'm utilizing TCP MSS Clamping to get rid of MTU issues associated with using a PPPoE link: joel@router:~$ sudo iptables -nvL <SNIP>...</SNIP> Chain FORWARD (policy ACCEPT 173M packets, 150G bytes) pkts bytes target prot opt in out source destination 279K 18M TCPMSS tcp -- * ppp1 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU <SNIP>...</SNIP> Here's my routing table: joel@router:~$ ip route ls default dev ppp1 scope link 10.254.32.18 dev ppp1 proto kernel scope link src 206.132.55.120 192.168.0.0/25 dev eth1 proto kernel scope link src 192.168.0.1 192.168.99.0/24 via 192.168.0.119 dev eth1 My normal LAN hosts work without issue. They can browse, stream, and participate in VoIP dialogs without issue. The same is not true for the hosts on 192.168.99.0/24. They can perform UDP conversations fine, but it seems like I'm having an issue with TCP traffic. In particular, TCP traffic to a remote host listening on port 5060 (SIP). Here's a packet capture that shows the behaviour that I'm seeing: joel@router:~$ sudo tshark -i any -f "host 76.11.36.4" Running as user "root" and group "root". This could be dangerous. Capturing on Pseudo-device that captures on all interfaces 0.000000 192.168.99.2 -> 76.11.36.4 TCP 60 52552 > sip [SYN] Seq=0 Win=8192 Len=0 MSS=1460 0.000070 206.132.55.120 -> 76.11.36.4 TCP 60 52552 > sip [SYN] Seq=0 Win=8192 Len=0 MSS=1452 0.033584 76.11.36.4 -> 206.132.55.120 TCP 60 sip > 52552 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 3.031038 206.132.55.120 -> 76.11.36.4 ICMP 88 Destination unreachable (Host unreachable) 16.579561 192.168.99.2 -> 76.11.36.4 TCP 56 52552 > sip [RST] Seq=1756570816 Win=0 Len=0 16.579592 192.168.99.2 -> 76.11.36.4 TCP 56 52552 > sip [RST] Seq=1756570816 Win=0 Len=0 Here's the connection tracking table entry for this TCP stream: joel@router:~$ sudo conntrack -L | grep 76.11.36.4 tcp 6 54 SYN_RECV src=192.168.99.2 dst=76.11.36.4 sport=52552 dport=5060 src=76.11.36.4 dst=206.132.55.120 sport=5060 dport=52552 mark=0 use=1 conntrack v1.0.0 (conntrack-tools): 81 flow entries have been shown. My TCP SYN is coming in from the local host, is then forwarded out to the remote host, the SYN/ACK comes back, but then it is not forwarded to the local host. 3 seconds later, the linux firewall/router tells the remote host that the Destination host is unreachable. Can anyone explain this behaviour? I'm able to connect to port 5060 using any of my LAN computers that are directly connected to the 192.168.0.0/25 subnet, but anything behind the Adtran doesn't get the replies to the SYN packet. Joel Gerber Network Specialist Network Operations Eastlink E: Joel.Gerber@xxxxxxxxxxxxxxxx T: 519.786.1241 -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
