From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel Beckham" Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out Date: Wed, 5 Mar 2003 10:31:40 -0600 Sender: netfilter-admin@lists.netfilter.org Message-ID: <000401c2e334$bc987db0$0a02010a@danbeck> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01C2E302.68BC3600" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: Netfilter This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C2E302.68BC3600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm sending this in html format hoping the dump lines won't wrap. And = sorry for the length of the dumps. =3D) Using the configuration you suggested below, (the original configuration = I tried and the one that made the most sense to me also) I've dumped = both sides of the tunnel. Below is the output. From the data below, = it's obvious that any outgoing packets with a full payload (the payload = size is 1460) i.e. 09:29:05.797718 10.1.2.10.3969 > 129.41.69.137.smtp: . = 165:1625(1460) ack 125 win 64116 (DF) never make it to the tunnel interface. This is why incoming imap = appears to work just fine, but sending mail doesn't. Again, this seems a bit crazy as my FORWARD chain specifically allows = any traffic to and from eth1 and tun0. $IPTABLES -A FORWARD -i tun+ -j ACCEPT =20 $IPTABLES -A FORWARD -i tap+ -j ACCEPT $IPTABLES -A FORWARD -i eth1 -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT tcpdump data: Firewall on the local side of the tunnel: (tun0) 09:29:04.986164 10.1.2.10.3969 > 10.1.1.7.smtp: S 266730469:266730469(0) = win 64240 (DF) 09:29:05.031684 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) = ack 266730470 win 5840 (DF) 09:29:05.032048 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 1 win 64240 (DF) 09:29:05.070314 10.1.1.7.smtp > 10.1.2.10.3969: P 1:30(29) ack 1 win = 5840 (DF) 09:29:05.071048 10.1.2.10.3969 > 10.1.1.7.smtp: P 1:15(14) ack 30 win = 64211 (DF) 09:29:05.116340 10.1.1.7.smtp > 10.1.2.10.3969: . ack 15 win 5840 (DF) 09:29:05.117105 10.1.1.7.smtp > 10.1.2.10.3969: P 30:53(23) ack 15 win = 5840 (DF) 09:29:05.122915 10.1.2.10.3969 > 10.1.1.7.smtp: P 15:50(35) ack 53 win = 64188 (DF) 09:29:05.158822 10.1.1.7.smtp > 10.1.2.10.3969: P 53:61(8) ack 50 win = 5840 (DF) 09:29:05.159389 10.1.2.10.3969 > 10.1.1.7.smtp: P 50:81(31) ack 61 win = 64180 (DF) 09:29:05.199339 10.1.1.7.smtp > 10.1.2.10.3969: P 61:69(8) ack 81 win = 5840 (DF) 09:29:05.217269 10.1.2.10.3969 > 10.1.1.7.smtp: P 81:87(6) ack 69 win = 64172 (DF) 09:29:05.253722 10.1.1.7.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 win = 5840 (DF) 09:29:05.461527 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 (DF) 09:29:05.489089 10.1.1.7.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 win = 5840 (DF) 09:29:05.489324 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 (DF) 09:29:05.637836 10.1.2.10.3969 > 10.1.1.7.smtp: P 87:93(6) ack 82 win = 64159 (DF) 09:29:05.674820 10.1.1.7.smtp > 10.1.2.10.3969: P 82:95(13) ack 93 win = 5840 (DF) 09:29:05.675137 10.1.2.10.3969 > 10.1.1.7.smtp: P 93:128(35) ack 95 win = 64146 (DF) 09:29:05.711645 10.1.1.7.smtp > 10.1.2.10.3969: P 95:103(8) ack 128 win = 5840 (DF) 09:29:05.712153 10.1.2.10.3969 > 10.1.1.7.smtp: P 128:159(31) ack 103 = win 64138 (DF) 09:29:05.760162 10.1.1.7.smtp > 10.1.2.10.3969: P 103:111(8) ack 159 win = 5840 (DF) 09:29:05.760485 10.1.2.10.3969 > 10.1.1.7.smtp: P 159:165(6) ack 111 win = 64130 (DF) 09:29:05.796928 10.1.1.7.smtp > 10.1.2.10.3969: P 111:125(14) ack 165 = win 5840 (DF) 09:29:05.798040 10.1.2.10.3969 > 10.1.1.7.smtp: P 4545:4763(218) ack 125 = win 64116 (DF) 09:29:05.798086 10.1.2.10.3969 > 10.1.1.7.smtp: P 4763:4768(5) ack 125 = win 64116 (DF) 09:29:05.834350 10.1.1.7.smtp > 10.1.2.10.3969: . ack 165 win 5840 = (DF) 09:29:05.846786 10.1.1.7.smtp > 10.1.2.10.3969: . ack 165 win 5840 = (DF) Remote side of the tunnel: (tun0) 12:08:10.673521 10.1.2.10.3969 > 10.1.1.7.smtp: S 266730469:266730469(0) = win 64240 (DF) 12:08:10.674685 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) = ack 266730470 win 5840 (DF) 12:08:10.718701 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 1 win 64240 (DF) 12:08:10.722990 10.1.1.7.smtp > 10.1.2.10.3969: P 1:30(29) ack 1 win = 5840 (DF) 12:08:10.761777 10.1.2.10.3969 > 10.1.1.7.smtp: P 1:15(14) ack 30 win = 64211 (DF) 12:08:10.762026 10.1.1.7.smtp > 10.1.2.10.3969: . ack 15 win 5840 (DF) 12:08:10.762144 10.1.1.7.smtp > 10.1.2.10.3969: P 30:53(23) ack 15 win = 5840 (DF) 12:08:10.809779 10.1.2.10.3969 > 10.1.1.7.smtp: P 15:50(35) ack 53 win = 64188 (DF) 12:08:10.810126 10.1.1.7.smtp > 10.1.2.10.3969: P 53:61(8) ack 50 win = 5840 (DF) 12:08:10.846437 10.1.2.10.3969 > 10.1.1.7.smtp: P 50:81(31) ack 61 win = 64180 (DF) 12:08:10.851162 10.1.1.7.smtp > 10.1.2.10.3969: P 61:69(8) ack 81 win = 5840 (DF) 12:08:10.905777 10.1.2.10.3969 > 10.1.1.7.smtp: P 81:87(6) ack 69 win = 64172 (DF) 12:08:10.906068 10.1.1.7.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 win = 5840 (DF) 12:08:11.139331 10.1.1.7.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 win = 5840 (DF) 12:08:11.148104 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 (DF) 12:08:11.177095 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 (DF) 12:08:11.324853 10.1.2.10.3969 > 10.1.1.7.smtp: P 87:93(6) ack 82 win = 64159 (DF) 12:08:11.325240 10.1.1.7.smtp > 10.1.2.10.3969: P 82:95(13) ack 93 win = 5840 (DF) 12:08:11.363484 10.1.2.10.3969 > 10.1.1.7.smtp: P 93:128(35) ack 95 win = 64146 (DF) 12:08:11.363818 10.1.1.7.smtp > 10.1.2.10.3969: P 95:103(8) ack 128 win = 5840 (DF) 12:08:11.412066 10.1.2.10.3969 > 10.1.1.7.smtp: P 128:159(31) ack 103 = win 64138 (DF) 12:08:11.412477 10.1.1.7.smtp > 10.1.2.10.3969: P 103:111(8) ack 159 win = 5840 (DF) 12:08:11.447083 10.1.2.10.3969 > 10.1.1.7.smtp: P 159:165(6) ack 111 win = 64130 (DF) 12:08:11.449412 10.1.1.7.smtp > 10.1.2.10.3969: P 111:125(14) ack 165 = win 5840 (DF) 12:08:11.486836 10.1.2.10.3969 > 10.1.1.7.smtp: P 4545:4763(218) ack 125 = win 64116 (DF) Here is the interesting part: Local side of the tunnel, but the eth1 (private network) interface: 09:29:04.986096 10.1.2.10.3969 > 129.41.69.137.smtp: S = 266730469:266730469(0) win 64240 (DF) 09:29:05.031723 129.41.69.137.smtp > 10.1.2.10.3969: S = 361700781:361700781(0) ack 266730470 win 5840 = (DF) 09:29:05.032012 10.1.2.10.3969 > 129.41.69.137.smtp: . ack 1 win 64240 = (DF) 09:29:05.070351 129.41.69.137.smtp > 10.1.2.10.3969: P 1:30(29) ack 1 = win 5840 (DF) 09:29:05.071015 10.1.2.10.3969 > 129.41.69.137.smtp: P 1:15(14) ack 30 = win 64211 (DF) 09:29:05.116376 129.41.69.137.smtp > 10.1.2.10.3969: . ack 15 win 5840 = (DF) 09:29:05.117139 129.41.69.137.smtp > 10.1.2.10.3969: P 30:53(23) ack 15 = win 5840 (DF) 09:29:05.122880 10.1.2.10.3969 > 129.41.69.137.smtp: P 15:50(35) ack 53 = win 64188 (DF) 09:29:05.158861 129.41.69.137.smtp > 10.1.2.10.3969: P 53:61(8) ack 50 = win 5840 (DF) 09:29:05.159354 10.1.2.10.3969 > 129.41.69.137.smtp: P 50:81(31) ack 61 = win 64180 (DF) 09:29:05.199376 129.41.69.137.smtp > 10.1.2.10.3969: P 61:69(8) ack 81 = win 5840 (DF) 09:29:05.217234 10.1.2.10.3969 > 129.41.69.137.smtp: P 81:87(6) ack 69 = win 64172 (DF) 09:29:05.253760 129.41.69.137.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 = win 5840 (DF) 09:29:05.461468 10.1.2.10.3969 > 129.41.69.137.smtp: . ack 82 win 64159 = (DF) 09:29:05.489124 129.41.69.137.smtp > 10.1.2.10.3969: P 69:82(13) ack 87 = win 5840 (DF) 09:29:05.489289 10.1.2.10.3969 > 129.41.69.137.smtp: . ack 82 win 64159 = (DF) 09:29:05.637796 10.1.2.10.3969 > 129.41.69.137.smtp: P 87:93(6) ack 82 = win 64159 (DF) 09:29:05.674856 129.41.69.137.smtp > 10.1.2.10.3969: P 82:95(13) ack 93 = win 5840 (DF) 09:29:05.675104 10.1.2.10.3969 > 129.41.69.137.smtp: P 93:128(35) ack 95 = win 64146 (DF) 09:29:05.711681 129.41.69.137.smtp > 10.1.2.10.3969: P 95:103(8) ack 128 = win 5840 (DF) 09:29:05.712122 10.1.2.10.3969 > 129.41.69.137.smtp: P 128:159(31) ack = 103 win 64138 (DF) 09:29:05.760198 129.41.69.137.smtp > 10.1.2.10.3969: P 103:111(8) ack = 159 win 5840 (DF) 09:29:05.760453 10.1.2.10.3969 > 129.41.69.137.smtp: P 159:165(6) ack = 111 win 64130 (DF) 09:29:05.796963 129.41.69.137.smtp > 10.1.2.10.3969: P 111:125(14) ack = 165 win 5840 (DF) 09:29:05.797718 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:05.797843 10.1.2.10.3969 > 129.41.69.137.smtp: . 1625:3085(1460) = ack 125 win 64116 (DF) 09:29:05.797966 10.1.2.10.3969 > 129.41.69.137.smtp: . 3085:4545(1460) = ack 125 win 64116 (DF) 09:29:05.797994 10.1.2.10.3969 > 129.41.69.137.smtp: P 4545:4763(218) = ack 125 win 64116 (DF) 09:29:05.798031 10.1.2.10.3969 > 129.41.69.137.smtp: P 4763:4768(5) ack = 125 win 64116 (DF) 09:29:05.834387 129.41.69.137.smtp > 10.1.2.10.3969: . ack 165 win 5840 = (DF) 09:29:05.846822 129.41.69.137.smtp > 10.1.2.10.3969: . ack 165 win 5840 = (DF) 09:29:05.847323 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:05.847445 10.1.2.10.3969 > 129.41.69.137.smtp: . 1625:3085(1460) = ack 125 win 64116 (DF) 09:29:05.847568 10.1.2.10.3969 > 129.41.69.137.smtp: . 3085:4545(1460) = ack 125 win 64116 (DF) 09:29:06.555338 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:08.195721 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:11.367205 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:17.819496 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) 09:29:30.614817 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) = ack 125 win 64116 (DF) ----- Original Message -----=20 From: To: "Daniel Beckham" Sent: Wednesday, March 05, 2003 3:58 AM Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't check out >=20 > Hi Daniel, >=20 > What a bitch of a problem ;-) Seeing as you haven't mentioned external > clients connecting to the mail server (via the eth0 interface), I = assume > that they can connect ok, right ? so the problem must lie somewhere in = the > tun0<->eth1 routing/DNAT/ip setup. >=20 > Having re-read through the posts below, you should have two (NAT) = rules > that govern the interaction between these two interfaces, one to allow = your > 10.1.2.10 client to connect to the 129.... address space (actually = using a > 10.1.1... address), and one to allow the 129..... address space to = connect > back to the 10.1.2... clients, right ?, so you'll need two rules, as > follows : >=20 > iptables -t nat -A PREROUTING -s 10.1.2.10 -d 129.41.69.137 -j DNAT = --to > 10.1.1.7 #this is for eth1->tun0 connections >=20 > iptables -t nat POSTROUTING -s 10.1.1.7 -d 10.1.2.10 -j SNAT --to > 129.41.69.137 # this is for tun0->eth1 connections >=20 > ... I don't know if you've tried this combination yet, but if my = thinking > of your network setup is correct, this should be the definative set of > SNAT/DNAT rules that you should use (and should work). >=20 > As for the filtering part of your setup, that all looks fine to me, I = mean > you basically just allow anything from tun0 and eth1 to be forwarded > across, right ? so there should be no problems there .... >=20 > Another idea, you say that you have dumped the tcp stuff at the remote > network, have you run a tcpdump on the local firewall to see what = happens > as the packets come back (ie they could be being routed through eth0, > instead of eth1 for some reason) .... can you tell I'm now clutching = at > straws ;-) >=20 > Apart from the revised NAT rules above, and trawling through a couple = of > tcpdumps (one at the remote end, one at the firewall end), I can't = really > think of anything else that could be causing the behaviour you are > experiencing (the upload/download and small emails issues are really > wierd), if the above rules do not solve it I would be looking towards = the > routing tables in the firewall, mail server and client machines, and = also > be looking to see if there are any old static hosts file entries etc = ... ie > looking at it from more of a tcp/ip based problem, rather than a = purely > iptables based problem, which the tcpdumps should help you with. >=20 > Hope this helps, > Richard. >=20 > Richard Oatridge > Head of IT, Start-global Ltd > http://www.start-global.com. > tel : +44 1564 779297 > email : richardo@start-global.com >=20 >=20 > |--------+-----------------------------------> > | | "Daniel Beckham" | > | | | | ws.com> | > | | Sent by: | > | | netfilter-admin@lists.net| > | | filter.org | > | | | > | | | > | | 04/03/2003 17:26 | > | | | > |--------+-----------------------------------> > = >------------------------------------------------------------------------= -------------------------------------------------| > | = | > | To: "Netfilter" = | > | cc: = | > | Subject: Re: DNAT and VPN Tunnel problems, traffic = checks in, but doesn't check out | > = >------------------------------------------------------------------------= -------------------------------------------------| >=20 >=20 >=20 >=20 > Yeah, I actually DNAT and SNAT private addresses to public addresses = on the > public interface on the firewall for some of the developers here, so I = know > that using that SNAT line *should* work, as it does in practice = already. >=20 > To answer your questions, here is the interface setup on the firewall. >=20 > eth0 -- public interface (207.111.175.64/26) to the external router > (internet) and normal traffic from and to the 129.41.69.128/26 subnet = comes > over this wire > eth1 -- private interface to local network using 10.1.2.0/24 address = space > tun0 -- a openvpn tunnel between the remote 10.1.1.0/24 network and = private > 10.1.2.0/24 network >=20 > The remote network is a private address space behind a router in the = public > 129.41.69.128/26 address space. The eth0 interface does not = specifically > listen for traffic from 129.41.69.137, instead it's just the gateway = for > any > external public traffic incoming to the 207.111.175.64/26 subnet. = There > are > also several eth0:N aliases for local private machines that are > DNAT/SNAT'ed > to public addresses for different reasons. >=20 > I use the following lines to allow all traffic to be forwarded from = the > private interface (eth1) and the openvpn tunnel (tun0): > $IPTABLES -A FORWARD -i tun+ -j ACCEPT > $IPTABLES -A FORWARD -i tap+ -j ACCEPT > $IPTABLES -A FORWARD -i eth1 -j ACCEPT > $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT >=20 > The line for the tap device isn't really necessary for my setup, but = it is > just there in case I decide to fool with bridging. >=20 > As far as I can tell, things should be working correctly. And the = funny > thing is that they do, sort of. Responses to the DNAT'ed traffic = initiated > by the client returns over the tunnel, but only part of the response > traffic > by the client goes back out. I.e. I can send very tiny emails, but = nothing > large like a reply. I can download files via ftp, but can not upload. > And > I've confirmed that traffic outgoing from the client is going over the > tunnel. >=20 > This is driving me crazy. =3D) >=20 > Daniel Beckham > dealnews.com >=20 >=20 > ----- Original Message ----- > From: > To: "Daniel Beckham" > Sent: Tuesday, March 04, 2003 10:32 AM > Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't > check out >=20 >=20 > > > > Hi Daniel. > > > > The second rule you mention below would be correct and needed for = these > > connections to work properly, so keep it in there ..... a couple of > things > > I thought about, though ..... .did you setup an alias on the = firewall > box's > > 'external' network card to listen for packets destined for = 129.41.69.137 > ? > > ..... as follows : > > > > ifconfig ethWHATEVER:0 129.41.69.137 netmask your.mask.goes.here > > > > ... also, what does your filter table look like, is the FORWARD = chain > setup > > correctly to allow the connection through the firewall ? > > > > Regards, > > Richard. > > > > Richard Oatridge > > Head of IT, Start-global Ltd > > http://www.start-global.com > > tel : +44 1564 779297 > > email : richardo@start-global.com > > > > > > |--------+-----------------------------------> > > | | "Daniel Beckham" | > > | | > | | ws.com> | > > | | Sent by: | > > | | netfilter-admin@lists.net| > > | | filter.org | > > | | | > > | | | > > | | 04/03/2003 15:29 | > > | | | > > |--------+-----------------------------------> > > > > > = -------------------------------------------------------------------------= -- > ----------------------------------------------| > > | > | > > | To: "Netfilter" > | > > | cc: > | > > | Subject: Re: DNAT and VPN Tunnel problems, traffic = checks > in, but doesn't check out | > > > > > = -------------------------------------------------------------------------= -- > ----------------------------------------------| > > > > > > > > > > Thank you for your help, but I don't really understand what you are > trying > > to tell me. The first config line makes sense and that is similar = to > what > > I'm doing now. Although, I'm not using any specific ports because = I'm > > testing at the moment. > > > > The second line is confusing though. Why would I SNAT a 10.1.1.0/24 > > address > > to another 10.1.1.0/24 address? I was thinking you may have meant a > > 10.1.2.0/24 address, but that makes even less sense as that is the = client > > trying to connect in the first place. Also, why would you use a = 10.1.1.7 > > as > > the -d option, the destination address? Btw, I tried several > combinations > > including your example just for the hell of it, but none of them = work. =3D) > > > > Something that I did not mention before though is that I have tried = this: > > iptables -t nat -A POSTROUTING -s 10.1.1.7 -p tcp -j SNAT --to > > 129.41.69.137 > > > > I would think this would solve the problem, but this doesn't help. > Anyone > > else have any ideas? > > > > Thank you for your help, > > > > Daniel Beckham > > dealnews.com > > > > > > > > ----- Original Message ----- > > From: "Pavan Gokarn" > > To: "Daniel Beckham" > > Sent: Tuesday, March 04, 2003 12:15 AM > > Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't > > check out > > > > > > > yes daniel you'll need a rule to get the packets back from the = remote > > > network back into your network. > > > these will be the rules substitute them eoth you desired ip = addresses > > > for outgoing connection > > > # iptables -t nat -A PREROUTING -d 129.41.69.137 -p tcp --dport 25 = -j > > > DNAT --to 10.1.1.7 > > > for incomming replies > > > # iptables -t nat -A POSTROUTING -d 10.1.1.7 -p tcp --dport 25 -j > > SNAT --to > > > 10.1.1.something > > > > > > remember not to allow all types of connections to in and out = because > this > > > might cause a security threat. substitute the 10.1.1.something ip > address > > > with the ip that connects/talks to the 10.1.1.7 address. > > > this might work > > > hope this was helpful > > > regards > > > > > > ----- Original Message ----- > > > From: Daniel Beckham > > > To: > > > Sent: Tuesday, March 04, 2003 3:53 AM > > > Subject: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't > > check > > > out > > > > > > > > > > I'm seeing a strange issue with DNAT'ed traffic over a VPN. = Incoming > > > > packets arrive just fine, but outgoing traffic has trouble for = large > > > streams > > > > of tcp data. > > > > > > > > My setup is fairly simple. A group of machines on a private = network > > > behind > > > > a gateway/firewall (netfilter) connect through an OpenVPN tunnel = to a > > > remote > > > > group of machines on a different private network. > > > > > > > > Local subnet: 10.1.2.0/24 > > > > Remote Subnet 10.1.1.0/24 > > > > > > > > Client machines on the local subnet can freely talk to servers = on the > > > remote > > > > subnet through the vpn with out any problems. > > > > > > > > Until the vpn tunnel was functional, client machines on the = local > > private > > > > network connected to mail.dealnews.com to retrieve and send = mail, a > > public > > > > interface of the mail server on the remote private network. Now = that > > the > > > > vpn is working, they need to retrieve and send mail using the = private > > > > address 10.1.1.7. > > > > > > > > For several reasons, one being laptop administration, I don't = want to > > > change > > > > all of the mail client's ip addresses to 10.1.1.7. I want to = use > > iptables > > > > to DNAT packets headed for the public mail address > (mail.dealnews.com) > > to > > > > the private mail address 10.1.1.7 so that packets are routed = over the > > vpn > > > > instead of the internet. > > > > > > > > This is how I attempted to configure iptables: > > > > iptables -t nat -A PREROUTING -s 10.1.2.10 -d 129.41.69.137 -p = all -j > > > > DNAT --to-destination 10.1.1.7 > > > > > > > > The -s option is there so that I can test the config myself = without > > > Borking > > > > the rest of the network. > > > > > > > > This seems to work at first as I can see traffic sent from the = client > > to > > > > mail.dealnews.com over the tunnel interface on the remote = network. > > What > > > > happens though, is although that I can connect to the remote = mail > > server > > > > > > just fine through IMAP and even send out a very small email = message > > > through > > > > SMTP, large mail messages just stall and fail. Ftp is the same = way. > I > > > can > > > > transfer files from the remote server, but I can not send any > sizeable > > > file > > > > to the server. I know for sure that traffic is traveling over = the > vpn > > > > tunnel because I'm dumping the tunnel interface up at the remote > > network. > > > > This sounds like something to do with fragmentation or possibly > > something > > > > along that line of thinking, but I can not for the life of me = figure > > out > > > > what this is. > > > > > > > > I wondered if possibly, I needed another rule to DNAT packets = coming > > from > > > > the remote network over the tunnel back to the public > mail.dealnews.com > > ip > > > > address: > > > > iptables -t nat -A PREROUTING -s 129.41.69.37 -d 10.1.2.10 -p = all -j > > > > DNAT --to-destination 129.41.69.137 > > > > > > > > But this didn't seem to help anything. > > > > > > > > Could anyone help me figure out how I can work around this? = Again, > > > incoming > > > > traffic through the tunnel seems to work just fine, but outgoing > > traffic > > > > only half seems to work. As strange as that sounds. > > > > > > > > Thanks, > > > > > > > > Daniel > > > > dealnews.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 ------=_NextPart_000_008A_01C2E302.68BC3600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm sending this in html format hoping = the dump=20 lines won't wrap.  And sorry for the length of the dumps. = =3D)
 
Using the configuration you suggested=20 below, (the original configuration I tried and the one that made = the most=20 sense to me also) I've dumped both sides of the tunnel.  Below = is the=20 output.   From the data = below, it's=20 obvious that any outgoing packets with a full payload (the = payload size is=20 1460)
 
i.e. 09:29:05.797718 10.1.2.10.3969 = >=20 129.41.69.137.smtp: . 165:1625(1460) ack 125 win 64116 = (DF)
never make it to the tunnel = interface.  =20 This is why incoming imap appears to work just fine, but sending mail=20 doesn't.
 
Again, this seems a bit crazy as my = FORWARD chain=20 specifically allows any traffic to and from eth1 and tun0.
 
$IPTABLES -A FORWARD -i tun+ -j=20 ACCEPT       
$IPTABLES -A = FORWARD -i=20 tap+ -j ACCEPT
$IPTABLES -A FORWARD -i eth1 -j = ACCEPT
$IPTABLES=20 -A FORWARD -m state --state ESTABLISHED,RELATED -j = ACCEPT
tcpdump data:
 
Firewall on the local side of the = tunnel:=20 (tun0)
 
09:29:04.986164 10.1.2.10.3969 > = 10.1.1.7.smtp:=20 S 266730469:266730469(0) win 64240 <mss 1460,nop,nop,sackOK>=20 (DF)
09:29:05.031684 10.1.1.7.smtp > 10.1.2.10.3969: S=20 361700781:361700781(0) ack 266730470 win 5840 <mss = 1460,nop,nop,sackOK>=20 (DF)
09:29:05.032048 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 1 win = 64240=20 (DF)
09:29:05.070314 10.1.1.7.smtp > 10.1.2.10.3969: P 1:30(29) = ack 1 win=20 5840 (DF)
09:29:05.071048 10.1.2.10.3969 > 10.1.1.7.smtp: P = 1:15(14) ack=20 30 win 64211 (DF)
09:29:05.116340 10.1.1.7.smtp > 10.1.2.10.3969: = . ack 15=20 win 5840 (DF)
09:29:05.117105 10.1.1.7.smtp > 10.1.2.10.3969: P = 30:53(23)=20 ack 15 win 5840 (DF)
09:29:05.122915 10.1.2.10.3969 > = 10.1.1.7.smtp: P=20 15:50(35) ack 53 win 64188 (DF)
09:29:05.158822 10.1.1.7.smtp >=20 10.1.2.10.3969: P 53:61(8) ack 50 win 5840 (DF)
09:29:05.159389=20 10.1.2.10.3969 > 10.1.1.7.smtp: P 50:81(31) ack 61 win 64180=20 (DF)
09:29:05.199339 10.1.1.7.smtp > 10.1.2.10.3969: P 61:69(8) = ack 81 win=20 5840 (DF)
09:29:05.217269 10.1.2.10.3969 > 10.1.1.7.smtp: P = 81:87(6) ack=20 69 win 64172 (DF)
09:29:05.253722 10.1.1.7.smtp > 10.1.2.10.3969: = P=20 69:82(13) ack 87 win 5840 (DF)
09:29:05.461527 10.1.2.10.3969 >=20 10.1.1.7.smtp: . ack 82 win 64159 (DF)
09:29:05.489089 10.1.1.7.smtp = >=20 10.1.2.10.3969: P 69:82(13) ack 87 win 5840 (DF)
09:29:05.489324=20 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 = (DF)
09:29:05.637836=20 10.1.2.10.3969 > 10.1.1.7.smtp: P 87:93(6) ack 82 win 64159=20 (DF)
09:29:05.674820 10.1.1.7.smtp > 10.1.2.10.3969: P 82:95(13) = ack 93=20 win 5840 (DF)
09:29:05.675137 10.1.2.10.3969 > 10.1.1.7.smtp: P = 93:128(35)=20 ack 95 win 64146 (DF)
09:29:05.711645 10.1.1.7.smtp > = 10.1.2.10.3969: P=20 95:103(8) ack 128 win 5840 (DF)
09:29:05.712153 10.1.2.10.3969 >=20 10.1.1.7.smtp: P 128:159(31) ack 103 win 64138 (DF)
09:29:05.760162=20 10.1.1.7.smtp > 10.1.2.10.3969: P 103:111(8) ack 159 win 5840=20 (DF)
09:29:05.760485 10.1.2.10.3969 > 10.1.1.7.smtp: P 159:165(6) = ack 111=20 win 64130 (DF)
09:29:05.796928 10.1.1.7.smtp > 10.1.2.10.3969: P=20 111:125(14) ack 165 win 5840 (DF)
09:29:05.798040 10.1.2.10.3969 > = 10.1.1.7.smtp: P 4545:4763(218) ack 125 win 64116 = (DF)
09:29:05.798086=20 10.1.2.10.3969 > 10.1.1.7.smtp: P 4763:4768(5) ack 125 win 64116=20 (DF)
09:29:05.834350 10.1.1.7.smtp > 10.1.2.10.3969: . ack 165 win = 5840=20 <nop,nop,sack sack 1 {4545:4763} > (DF)
09:29:05.846786 = 10.1.1.7.smtp=20 > 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 = {4545:4768} >=20 (DF)
Remote side of the tunnel: = (tun0)
 
12:08:10.673521 10.1.2.10.3969 > = 10.1.1.7.smtp:=20 S 266730469:266730469(0) win 64240 <mss 1460,nop,nop,sackOK>=20 (DF)
12:08:10.674685 10.1.1.7.smtp > 10.1.2.10.3969: S=20 361700781:361700781(0) ack 266730470 win 5840 <mss = 1460,nop,nop,sackOK>=20 (DF)
12:08:10.718701 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 1 win = 64240=20 (DF)
12:08:10.722990 10.1.1.7.smtp > 10.1.2.10.3969: P 1:30(29) = ack 1 win=20 5840 (DF)
12:08:10.761777 10.1.2.10.3969 > 10.1.1.7.smtp: P = 1:15(14) ack=20 30 win 64211 (DF)
12:08:10.762026 10.1.1.7.smtp > 10.1.2.10.3969: = . ack 15=20 win 5840 (DF)
12:08:10.762144 10.1.1.7.smtp > 10.1.2.10.3969: P = 30:53(23)=20 ack 15 win 5840 (DF)
12:08:10.809779 10.1.2.10.3969 > = 10.1.1.7.smtp: P=20 15:50(35) ack 53 win 64188 (DF)
12:08:10.810126 10.1.1.7.smtp >=20 10.1.2.10.3969: P 53:61(8) ack 50 win 5840 (DF)
12:08:10.846437=20 10.1.2.10.3969 > 10.1.1.7.smtp: P 50:81(31) ack 61 win 64180=20 (DF)
12:08:10.851162 10.1.1.7.smtp > 10.1.2.10.3969: P 61:69(8) = ack 81 win=20 5840 (DF)
12:08:10.905777 10.1.2.10.3969 > 10.1.1.7.smtp: P = 81:87(6) ack=20 69 win 64172 (DF)
12:08:10.906068 10.1.1.7.smtp > 10.1.2.10.3969: = P=20 69:82(13) ack 87 win 5840 (DF)
12:08:11.139331 10.1.1.7.smtp >=20 10.1.2.10.3969: P 69:82(13) ack 87 win 5840 (DF)
12:08:11.148104=20 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 = (DF)
12:08:11.177095=20 10.1.2.10.3969 > 10.1.1.7.smtp: . ack 82 win 64159 = (DF)
12:08:11.324853=20 10.1.2.10.3969 > 10.1.1.7.smtp: P 87:93(6) ack 82 win 64159=20 (DF)
12:08:11.325240 10.1.1.7.smtp > 10.1.2.10.3969: P 82:95(13) = ack 93=20 win 5840 (DF)
12:08:11.363484 10.1.2.10.3969 > 10.1.1.7.smtp: P = 93:128(35)=20 ack 95 win 64146 (DF)
12:08:11.363818 10.1.1.7.smtp > = 10.1.2.10.3969: P=20 95:103(8) ack 128 win 5840 (DF)
12:08:11.412066 10.1.2.10.3969 >=20 10.1.1.7.smtp: P 128:159(31) ack 103 win 64138 (DF)
12:08:11.412477=20 10.1.1.7.smtp > 10.1.2.10.3969: P 103:111(8) ack 159 win 5840=20 (DF)
12:08:11.447083 10.1.2.10.3969 > 10.1.1.7.smtp: P 159:165(6) = ack 111=20 win 64130 (DF)
12:08:11.449412 10.1.1.7.smtp > 10.1.2.10.3969: P=20 111:125(14) ack 165 win 5840 (DF)
12:08:11.486836 10.1.2.10.3969 > = 10.1.1.7.smtp: P 4545:4763(218) ack 125 win 64116 (DF)
 
Here is the interesting = part:
Local side of the tunnel, but the eth1 = (private=20 network) interface:
 
09:29:04.986096 10.1.2.10.3969 >=20 129.41.69.137.smtp: S 266730469:266730469(0) win 64240 <mss=20 1460,nop,nop,sackOK> (DF)
09:29:05.031723 129.41.69.137.smtp >=20 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss=20 1460,nop,nop,sackOK> (DF)
09:29:05.032012 10.1.2.10.3969 >=20 129.41.69.137.smtp: . ack 1 win 64240 (DF)
09:29:05.070351 = 129.41.69.137.smtp=20 > 10.1.2.10.3969: P 1:30(29) ack 1 win 5840 (DF)
09:29:05.071015=20 10.1.2.10.3969 > 129.41.69.137.smtp: P 1:15(14) ack 30 win 64211=20 (DF)
09:29:05.116376 129.41.69.137.smtp > 10.1.2.10.3969: . ack 15 = win=20 5840 (DF)
09:29:05.117139 129.41.69.137.smtp > 10.1.2.10.3969: P = 30:53(23)=20 ack 15 win 5840 (DF)
09:29:05.122880 10.1.2.10.3969 > = 129.41.69.137.smtp:=20 P 15:50(35) ack 53 win 64188 (DF)
09:29:05.158861 129.41.69.137.smtp = >=20 10.1.2.10.3969: P 53:61(8) ack 50 win 5840 (DF)
09:29:05.159354=20 10.1.2.10.3969 > 129.41.69.137.smtp: P 50:81(31) ack 61 win 64180=20 (DF)
09:29:05.199376 129.41.69.137.smtp > 10.1.2.10.3969: P = 61:69(8) ack=20 81 win 5840 (DF)
09:29:05.217234 10.1.2.10.3969 > = 129.41.69.137.smtp: P=20 81:87(6) ack 69 win 64172 (DF)
09:29:05.253760 129.41.69.137.smtp = >=20 10.1.2.10.3969: P 69:82(13) ack 87 win 5840 (DF)
09:29:05.461468=20 10.1.2.10.3969 > 129.41.69.137.smtp: . ack 82 win 64159=20 (DF)
09:29:05.489124 129.41.69.137.smtp > 10.1.2.10.3969: P = 69:82(13) ack=20 87 win 5840 (DF)
09:29:05.489289 10.1.2.10.3969 > = 129.41.69.137.smtp: .=20 ack 82 win 64159 (DF)
09:29:05.637796 10.1.2.10.3969 > = 129.41.69.137.smtp:=20 P 87:93(6) ack 82 win 64159 (DF)
09:29:05.674856 129.41.69.137.smtp = >=20 10.1.2.10.3969: P 82:95(13) ack 93 win 5840 (DF)
09:29:05.675104=20 10.1.2.10.3969 > 129.41.69.137.smtp: P 93:128(35) ack 95 win 64146=20 (DF)
09:29:05.711681 129.41.69.137.smtp > 10.1.2.10.3969: P = 95:103(8) ack=20 128 win 5840 (DF)
09:29:05.712122 10.1.2.10.3969 > = 129.41.69.137.smtp: P=20 128:159(31) ack 103 win 64138 (DF)
09:29:05.760198 129.41.69.137.smtp = >=20 10.1.2.10.3969: P 103:111(8) ack 159 win 5840 (DF)
09:29:05.760453=20 10.1.2.10.3969 > 129.41.69.137.smtp: P 159:165(6) ack 111 win 64130=20 (DF)
09:29:05.796963 129.41.69.137.smtp > 10.1.2.10.3969: P = 111:125(14)=20 ack 165 win 5840 (DF)
09:29:05.797718 10.1.2.10.3969 > = 129.41.69.137.smtp:=20 . 165:1625(1460) ack 125 win 64116 (DF)
09:29:05.797843 = 10.1.2.10.3969 >=20 129.41.69.137.smtp: . 1625:3085(1460) ack 125 win 64116 = (DF)
09:29:05.797966=20 10.1.2.10.3969 > 129.41.69.137.smtp: . 3085:4545(1460) ack 125 win = 64116=20 (DF)
09:29:05.797994 10.1.2.10.3969 > 129.41.69.137.smtp: P = 4545:4763(218)=20 ack 125 win 64116 (DF)
09:29:05.798031 10.1.2.10.3969 >=20 129.41.69.137.smtp: P 4763:4768(5) ack 125 win 64116 = (DF)
09:29:05.834387=20 129.41.69.137.smtp > 10.1.2.10.3969: . ack 165 win 5840 = <nop,nop,sack sack=20 1 {4545:4763} > (DF)
09:29:05.846822 129.41.69.137.smtp >=20 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 {4545:4768} = >=20 (DF)
09:29:05.847323 10.1.2.10.3969 > 129.41.69.137.smtp: . = 165:1625(1460)=20 ack 125 win 64116 (DF)
09:29:05.847445 10.1.2.10.3969 >=20 129.41.69.137.smtp: . 1625:3085(1460) ack 125 win 64116 = (DF)
09:29:05.847568=20 10.1.2.10.3969 > 129.41.69.137.smtp: . 3085:4545(1460) ack 125 win = 64116=20 (DF)
09:29:06.555338 10.1.2.10.3969 > 129.41.69.137.smtp: . = 165:1625(1460)=20 ack 125 win 64116 (DF)
09:29:08.195721 10.1.2.10.3969 >=20 129.41.69.137.smtp: . 165:1625(1460) ack 125 win 64116 = (DF)
09:29:11.367205=20 10.1.2.10.3969 > 129.41.69.137.smtp: . 165:1625(1460) ack 125 win = 64116=20 (DF)
09:29:17.819496 10.1.2.10.3969 > 129.41.69.137.smtp: . = 165:1625(1460)=20 ack 125 win 64116 (DF)
09:29:30.614817 10.1.2.10.3969 >=20 129.41.69.137.smtp: . 165:1625(1460) ack 125 win 64116 = (DF)
 
 
----- Original Message -----
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Wednesday, March 05, 2003 3:58=20 AM
Subject: Re: DNAT and VPN Tunnel = problems, traffic=20 checks in, but doesn't check out

>
> Hi Daniel,
>
> What a bitch of a = problem ;-)=20 Seeing as you haven't mentioned external
> clients connecting to = the mail=20 server (via the eth0 interface), I assume
> that they can connect = ok,=20 right ? so the problem must lie somewhere in the
> = tun0<->eth1=20 routing/DNAT/ip setup.
>
> Having re-read through the posts = below,=20 you should have two (NAT) rules
> that govern the interaction = between=20 these two interfaces, one to allow your
> 10.1.2.10 client to = connect to=20 the 129.... address space (actually using a
> 10.1.1... address), = and one=20 to allow the 129..... address space to connect
> back to the = 10.1.2...=20 clients, right ?, so you'll need two rules, as
> follows :
> =
> iptables -t nat -A PREROUTING -s 10.1.2.10 -d 129.41.69.137 -j = DNAT=20 --to
>=20 10.1.1.7           = ; #this=20 is for eth1->tun0 connections
>
> iptables -t nat = POSTROUTING -s=20 10.1.1.7 -d 10.1.2.10 -j SNAT --to
>=20 129.41.69.137          =  =20 # this is for tun0->eth1 connections
>
> ... I don't = know if=20 you've tried this combination yet, but if my thinking
> of your = network=20 setup is correct, this should be the definative set of
> SNAT/DNAT = rules=20 that you should use (and should work).
>
> As for the = filtering=20 part of your setup, that all looks fine to me, I mean
> you = basically just=20 allow anything from tun0 and eth1 to be forwarded
> across, right = ? so=20 there should be no problems there ....
>
> Another idea, = you say=20 that you have dumped the tcp stuff at the remote
> network, have = you run a=20 tcpdump on the local firewall to see what happens
> as the packets = come=20 back (ie they could be being routed through eth0,
> instead of = eth1 for=20 some reason) .... can you tell I'm now clutching at
> straws = ;-)
>=20
> Apart from the revised NAT rules above, and trawling through a = couple=20 of
> tcpdumps (one at the remote end, one at the firewall end), I = can't=20 really
> think of anything else that could be causing the = behaviour you=20 are
> experiencing (the upload/download and small emails issues = are=20 really
> wierd), if the above rules do not solve it I would be = looking=20 towards the
> routing tables in the firewall, mail server and = client=20 machines, and also
> be looking to see if there are any old static = hosts=20 file entries etc ... ie
> looking at it from more of a tcp/ip = based=20 problem, rather than a purely
> iptables based problem, which the = tcpdumps=20 should help you with.
>
> Hope this helps,
> = Richard.
>=20
> Richard Oatridge
> Head of IT, Start-global Ltd
> = http://www.start-global.com.
>=20 tel :  +44 1564 779297
> email : richardo@start-global.com
>=20
>
> = |--------+----------------------------------->
>=20 |       =20 |          "Daniel=20 Beckham"         |
>=20 |       =20 |          <danbeck-netfilter@dealne|
>=20 |       =20 |         =20 ws.com>          &nb= sp;      =20 |
> |       =20 |          Sent=20 by:           &nbs= p;    =20 |
> |       =20 |          netfilter-admin@lists.net|
>=20 |       =20 |         =20 filter.org          &nb= sp;   =20 |
> |       =20 |            =             &= nbsp;         =20 |
> |       =20 |            =             &= nbsp;         =20 |
> |       =20 |          04/03/2003=20 17:26         |
>=20 |       =20 |            =             &= nbsp;         =20 |
> |--------+----------------------------------->
> =  =20 >---------------------------------------------------------------------= ----------------------------------------------------|
>=20  =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;          =20 |
>   |      =20 To:     "Netfilter" <netfilter@lists.netfilter.org>          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   =20 |
>   |      =20 cc:           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20 |
>   |      =20 Subject:     Re: DNAT and VPN Tunnel problems, = traffic=20 checks in, but doesn't check=20 out           &nbs= p;            = ;  =20 |
>  =20 >---------------------------------------------------------------------= ----------------------------------------------------|
>=20
>
>
>
> Yeah, I actually DNAT and SNAT = private=20 addresses to public addresses on the
> public interface on the = firewall=20 for some of the developers here, so I know
> that using that SNAT = line=20 *should* work, as it does in practice already.
>
> To = answer your=20 questions, here is the interface setup on the firewall.
>
> = eth0 --=20 public interface (207.111.175.64/26) to the external router
> = (internet)=20 and normal traffic from and to the 129.41.69.128/26 subnet comes
> = over=20 this wire
> eth1 -- private interface to local network using = 10.1.2.0/24=20 address space
> tun0 -- a openvpn tunnel between the remote = 10.1.1.0/24=20 network and private
> 10.1.2.0/24 network
>
> The = remote=20 network is a private address space behind a router in the public
> = 129.41.69.128/26 address space.  The eth0 interface does not=20 specifically
> listen for traffic from 129.41.69.137, instead it's = just=20 the gateway for
> any
> external public traffic incoming to = the=20 207.111.175.64/26 subnet.  There
> are
> also several = eth0:N=20 aliases for local private machines that are
> DNAT/SNAT'ed
> = to=20 public addresses for different reasons.
>
> I use the = following=20 lines to allow all traffic to be forwarded from the
> private = interface=20 (eth1) and the openvpn tunnel (tun0):
> $IPTABLES -A FORWARD -i = tun+ -j=20 ACCEPT
> $IPTABLES -A FORWARD -i tap+ -j ACCEPT
> $IPTABLES = -A=20 FORWARD -i eth1 -j ACCEPT
> $IPTABLES -A FORWARD -m state --state=20 ESTABLISHED,RELATED -j ACCEPT
>
> The line for the tap = device isn't=20 really necessary for my setup, but it is
> just there in case I = decide to=20 fool with bridging.
>
> As far as I can tell, things should = be=20 working correctly.  And the funny
> thing is that they do, = sort=20 of.  Responses to the DNAT'ed traffic initiated
> by the = client=20 returns over the tunnel, but only part of the response
> = traffic
>=20 by the client goes back out.  I.e. I can send very tiny emails, but = nothing
> large like a reply.  I can download files via ftp, = but can=20 not upload.
> And
> I've confirmed that traffic outgoing = from the=20 client is going over the
> tunnel.
>
> This is = driving me=20 crazy. =3D)
>
> Daniel Beckham
> dealnews.com
> =
>=20
> ----- Original Message -----
> From: <richardo@start-global.com>
>=20 To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
> Sent: Tuesday, March 04, 2003 10:32 AM
> = Subject: Re:=20 DNAT and VPN Tunnel problems, traffic checks in, but doesn't
> = check=20 out
>
>
> >
> > Hi Daniel.
> = >
>=20 > The second rule you mention below would be correct and needed for=20 these
> > connections to work properly, so keep it in there = ..... a=20 couple of
> things
> > I thought about, though ..... .did = you=20 setup an alias on the firewall
> box's
> > 'external' = network=20 card to listen for packets destined for 129.41.69.137
> ?
> = >=20 ..... as follows :
> >
> > ifconfig ethWHATEVER:0=20 129.41.69.137 netmask your.mask.goes.here
> >
> > ... = also,=20 what does your filter table look like, is the FORWARD chain
>=20 setup
> > correctly to allow the connection through the = firewall=20 ?
> >
> > Regards,
> > Richard.
> = >
>=20 > Richard Oatridge
> > Head of IT, Start-global Ltd
> = >=20 http://www.start-global.com
>=20 > tel :  +44 1564 779297
> > email : richardo@start-global.com
>=20 >
> >
> >=20 |--------+----------------------------------->
> >=20 |       =20 |          "Daniel=20 Beckham"         |
> >=20 |       =20 |          <danbeck-netfilter@dealne|
> >=20 |       =20 |         =20 ws.com>          &nb= sp;      =20 |
> > |       =20 |          Sent=20 by:           &nbs= p;    =20 |
> > |       =20 |          netfilter-admin@lists.net|
>=20 > |       =20 |         =20 filter.org          &nb= sp;   =20 |
> > |       =20 |            =             &= nbsp;         =20 |
> > |       =20 |            =             &= nbsp;         =20 |
> > |       =20 |          04/03/2003=20 15:29         |
> >=20 |       =20 |            =             &= nbsp;         =20 |
> > |--------+----------------------------------->
> = >
> >
>=20 -------------------------------------------------------------------------= --
>=20 ----------------------------------------------|
> >   = |
> |
> >   = |      =20 To:     "Netfilter" <netfilter@lists.netfilter.org>
> |
> >  =20 |       cc:
> |
> = >  =20 |       Subject:     = Re: DNAT=20 and VPN Tunnel problems, traffic checks
> in, but doesn't check=20 out           &nbs= p;            = ;  =20 |
> >
> >
>=20 -------------------------------------------------------------------------= --
>=20 ----------------------------------------------|
> >
>=20 >
> >
> >
> > Thank you for your help, but = I don't=20 really understand what you are
> trying
> > to tell = me.  The=20 first config line makes sense and that is similar to
> = what
> >=20 I'm doing now.  Although, I'm not using any specific ports because=20 I'm
> > testing at the moment.
> >
> > The = second=20 line is confusing though.  Why would I SNAT a 10.1.1.0/24
> = >=20 address
> > to another 10.1.1.0/24 address?  I was = thinking you=20 may have meant a
> > 10.1.2.0/24 address, but that makes even = less=20 sense as that is the client
> > trying to connect in the first=20 place.  Also, why would you use a 10.1.1.7
> > as
> = > the=20 -d option, the destination address?  Btw, I tried several
>=20 combinations
> > including your example just for the hell of = it, but=20 none of them work. =3D)
> >
> > Something that I did = not mention=20 before though is that I have tried this:
> > iptables -t nat -A = POSTROUTING -s 10.1.1.7 -p tcp -j SNAT --to
> > = 129.41.69.137
>=20 >
> > I would think this would solve the problem, but this = doesn't=20 help.
> Anyone
> > else have any ideas?
> = >
> >=20 Thank you for your help,
> >
> > Daniel = Beckham
> >=20 dealnews.com
> >
> >
> >
> > ----- = Original=20 Message -----
> > From: "Pavan Gokarn" <pavang@techknowledge.ws>
>=20 > To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
> > Sent: Tuesday, March 04, 2003 12:15 = AM
> >=20 Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but=20 doesn't
> > check out
> >
> >
> > = > yes=20 daniel you'll need a rule to get the packets back from the = remote
> >=20 > network back into your network.
> > > these will be the = rules=20 substitute them eoth you desired ip addresses
> > > for = outgoing=20 connection
> > > # iptables -t nat -A PREROUTING -d = 129.41.69.137 -p=20 tcp --dport 25 -j
> > > DNAT --to 10.1.1.7
> > > = for=20 incomming replies
> > > # iptables -t nat -A POSTROUTING -d = 10.1.1.7=20 -p tcp --dport 25 -j
> > SNAT --to
> > >=20 10.1.1.something
> > >
> > > remember not to = allow all=20 types of connections to in and out because
> this
> > = > might=20 cause a security threat. substitute the 10.1.1.something ip
>=20 address
> > > with the ip that connects/talks to the = 10.1.1.7=20 address.
> > > this might work
> > > hope this = was=20 helpful
> > > regards
> > >
> > > = -----=20 Original Message -----
> > > From: Daniel Beckham = <danbeck-netfilter@dealnews.com>
> > > To: <netfilter@lists.netfilter.org>
> > > Sent: Tuesday, March 04, 2003 3:53 = AM
> >=20 > Subject: DNAT and VPN Tunnel problems, traffic checks in, but=20 doesn't
> > check
> > > out
> > = >
> >=20 >
> > > > I'm seeing a strange issue with DNAT'ed = traffic over=20 a VPN.  Incoming
> > > > packets arrive just fine, = but=20 outgoing traffic has trouble for large
> > > streams
> = >=20 > > of tcp data.
> > > >
> > > > My = setup is=20 fairly simple.   A group of machines on a private = network
> >=20 > behind
> > > > a gateway/firewall (netfilter) = connect=20 through an OpenVPN tunnel to a
> > > remote
> > = > >=20 group of machines on a different private network.
> > > = >
>=20 > > > Local subnet: 10.1.2.0/24
> > > > Remote = Subnet=20 10.1.1.0/24
> > > >
> > > > Client = machines on the=20 local subnet can freely talk to servers on the
> > > = remote
>=20 > > > subnet through the vpn with out any problems.
> = > >=20 >
> > > > Until the vpn tunnel was functional, client = machines=20 on the local
> > private
> > > > network = connected to=20 mail.dealnews.com to retrieve and send mail, a
> > = public
> >=20 > > interface of the mail server on the remote private = network.  Now=20 that
> > the
> > > > vpn is working, they need = to=20 retrieve and send mail using the private
> > > > address=20 10.1.1.7.
> > > >
> > > > For several = reasons, one=20 being laptop administration, I don't want to
> > > = change
>=20 > > > all of the mail client's ip addresses to 10.1.1.7.  = I want=20 to use
> > iptables
> > > > to DNAT packets = headed for=20 the public mail address
> (mail.dealnews.com)
> > = to
> >=20 > > the private mail address 10.1.1.7 so that packets are routed = over=20 the
> > vpn
> > > > instead of the = internet.
>=20 > > >
> > > > This is how I attempted to = configure=20 iptables:
> > > > iptables -t nat -A PREROUTING -s = 10.1.2.10 -d=20 129.41.69.137 -p all -j
> > > > DNAT --to-destination=20 10.1.1.7
> > > >
> > > > The -s option is = there so=20 that I can test the config myself without
> > > = Borking
> >=20 > > the rest of the network.
> > > >
> > = > >=20 This seems to work at first as I can see traffic sent from the = client
>=20 > to
> > > > mail.dealnews.com over the tunnel = interface on=20 the remote network.
> > What
> > > > happens = though, is=20 although that I can connect to the remote mail
> > = server
>=20 >
> > > > just fine through IMAP and even send out a = very=20 small email message
> > > through
> > > > = SMTP, large=20 mail messages just stall and fail.  Ftp is the same way.
> = I
>=20 > > can
> > > > transfer files from the remote = server, but=20 I can not send any
> sizeable
> > > file
> > = >=20 > to the server.  I know for sure that traffic is traveling over = the
> vpn
> > > > tunnel because I'm dumping the = tunnel=20 interface up at the remote
> > network.
> > > > = This=20 sounds like something to do with fragmentation or possibly
> >=20 something
> > > > along that line of thinking, but I can = not for=20 the life of me figure
> > out
> > > > what this=20 is.
> > > >
> > > > I wondered if = possibly, I=20 needed another rule to DNAT packets coming
> > from
> = > >=20 > the remote network over the tunnel back to the public
>=20 mail.dealnews.com
> > ip
> > > > = address:
> >=20 > > iptables -t nat -A PREROUTING -s 129.41.69.37 -d 10.1.2.10 -p = all=20 -j
> > > > DNAT --to-destination 129.41.69.137
> = > >=20 >
> > > > But this didn't seem to help = anything.
> >=20 > >
> > > > Could anyone help me figure out how I = can work=20 around this?  Again,
> > > incoming
> > > = >=20 traffic through the tunnel seems to work just fine, but outgoing
> = >=20 traffic
> > > > only half seems to work.  As strange = as that=20 sounds.
> > > >
> > > > Thanks,
> = > >=20 >
> > > > Daniel
> > > > = dealnews.com
>=20 > > >
> > > >
> > > >
> = > >=20 >
> > >
> > >
> >
> = >
>=20 >
> >
> >
> >
> >
> = >
>=20 >
>
>
>
>
>
>
> =
>=20
>
> ------=_NextPart_000_008A_01C2E302.68BC3600--