Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

Linux Netfilter discussions
 help / color / mirror / Atom feed

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found] <OFB7840FE4.C0F00E27-ON80256CE0.0031E466@start-global.com>
@ 2003-03-05 16:31 ` Daniel Beckham
  2003-03-05 16:38 ` Daniel Beckham
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Beckham @ 2003-03-05 16:31 UTC (permalink / raw)
  To: Netfilter

[-- Attachment #1: Type: text/plain, Size: 23976 bytes --]

I'm sending this in html format hoping the dump lines won't wrap.  And sorry for the length of the dumps. =)

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        
$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 <mss 1460,nop,nop,sackOK> (DF)
09:29:05.031684 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <nop,nop,sack sack 1 {4545:4763} > (DF)
09:29:05.846786 10.1.1.7.smtp > 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 {4545:4768} > (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 <mss 1460,nop,nop,sackOK> (DF)
12:08:10.674685 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <mss 1460,nop,nop,sackOK> (DF)
09:29:05.031723 129.41.69.137.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <nop,nop,sack sack 1 {4545:4763} > (DF)
09:29:05.846822 129.41.69.137.smtp > 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 {4545:4768} > (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 ----- 
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Wednesday, March 05, 2003 3:58 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out


> 
> Hi Daniel,
> 
> 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.
> 
> 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 :
> 
> 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
> 
> 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
> 
> ... 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).
> 
> 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 ....
> 
> 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 ;-)
> 
> 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.
> 
> Hope this helps,
> 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"         |
> |        |          <danbeck-netfilter@dealne|
> |        |          ws.com>                  |
> |        |          Sent by:                 |
> |        |          netfilter-admin@lists.net|
> |        |          filter.org               |
> |        |                                   |
> |        |                                   |
> |        |          04/03/2003 17:26         |
> |        |                                   |
> |--------+----------------------------------->
>   >-------------------------------------------------------------------------------------------------------------------------|
>   |                                                                                                                         |
>   |       To:     "Netfilter" <netfilter@lists.netfilter.org>                                                               |
>   |       cc:                                                                                                               |
>   |       Subject:     Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out                           |
>   >-------------------------------------------------------------------------------------------------------------------------|
> 
> 
> 
> 
> 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.
> 
> To answer your questions, here is the interface setup on the firewall.
> 
> 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
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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.
> 
> This is driving me crazy. =)
> 
> Daniel Beckham
> dealnews.com
> 
> 
> ----- Original Message -----
> From: <richardo@start-global.com>
> To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
> Sent: Tuesday, March 04, 2003 10:32 AM
> Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
> check out
> 
> 
> >
> > 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"         |
> > |        |          <danbeck-netfilter@dealne|
> > |        |          ws.com>                  |
> > |        |          Sent by:                 |
> > |        |          netfilter-admin@lists.net|
> > |        |          filter.org               |
> > |        |                                   |
> > |        |                                   |
> > |        |          04/03/2003 15:29         |
> > |        |                                   |
> > |--------+----------------------------------->
> >
> >
> ---------------------------------------------------------------------------
> ----------------------------------------------|
> >   |
> |
> >   |       To:     "Netfilter" <netfilter@lists.netfilter.org>
> |
> >   |       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. =)
> >
> > 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" <pavang@techknowledge.ws>
> > To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
> > 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 <danbeck-netfilter@dealnews.com>
> > > To: <netfilter@lists.netfilter.org>
> > > 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

[-- Attachment #2: Type: text/html, Size: 37643 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found] <OFB7840FE4.C0F00E27-ON80256CE0.0031E466@start-global.com>
  2003-03-05 16:31 ` DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out Daniel Beckham
@ 2003-03-05 16:38 ` Daniel Beckham
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Beckham @ 2003-03-05 16:38 UTC (permalink / raw)
  To: Netfilter

[-- Attachment #1: Type: text/plain, Size: 9355 bytes --]

I'm sending this in html format, hoping the dump lines won't wrap.   LOL, also, my original message was too long, so I've shortened it.. sorry if you all get one of these twice.

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        
$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 <mss 1460,nop,nop,sackOK> (DF)
09:29:05.031684 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <nop,nop,sack sack 1 {4545:4763} > (DF)
09:29:05.846786 10.1.1.7.smtp > 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 {4545:4768} > (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 <mss 1460,nop,nop,sackOK> (DF)
12:08:10.674685 10.1.1.7.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <mss 1460,nop,nop,sackOK> (DF)
09:29:05.031723 129.41.69.137.smtp > 10.1.2.10.3969: S 361700781:361700781(0) ack 266730470 win 5840 <mss 1460,nop,nop,sackOK> (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 <nop,nop,sack sack 1 {4545:4763} > (DF)
09:29:05.846822 129.41.69.137.smtp > 10.1.2.10.3969: . ack 165 win 5840 <nop,nop,sack sack 1 {4545:4768} > (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)



[-- Attachment #2: Type: text/html, Size: 11765 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

[parent not found: <OF3A1E747D.4950DEAF-ON80256CDF.005A4395@start-global.com>]

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found] <OF3A1E747D.4950DEAF-ON80256CDF.005A4395@start-global.com>
@ 2003-03-04 17:26 ` Daniel Beckham
       [not found]   ` <3E64E9A4.6010008@sqlcomp.com>
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Beckham @ 2003-03-04 17:26 UTC (permalink / raw)
  To: Netfilter

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.

To answer your questions, here is the interface setup on the firewall.

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

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.

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

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.

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.

This is driving me crazy. =)

Daniel Beckham
dealnews.com


----- Original Message -----
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Tuesday, March 04, 2003 10:32 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
check out


>
> 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"         |
> |        |          <danbeck-netfilter@dealne|
> |        |          ws.com>                  |
> |        |          Sent by:                 |
> |        |          netfilter-admin@lists.net|
> |        |          filter.org               |
> |        |                                   |
> |        |                                   |
> |        |          04/03/2003 15:29         |
> |        |                                   |
> |--------+----------------------------------->
>
>---------------------------------------------------------------------------
----------------------------------------------|
>   |
|
>   |       To:     "Netfilter" <netfilter@lists.netfilter.org>
|
>   |       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. =)
>
> 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" <pavang@techknowledge.ws>
> To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
> 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 <danbeck-netfilter@dealnews.com>
> > To: <netfilter@lists.netfilter.org>
> > 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
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>
>
>
>
>






^ permalink raw reply	[flat|nested] 8+ messages in thread

[parent not found: <3E64E9A4.6010008@sqlcomp.com>]

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found]   ` <3E64E9A4.6010008@sqlcomp.com>
@ 2003-03-04 18:56     ` Daniel Beckham
       [not found]       ` <3E64FD61.50107@sqlcomp.com>
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Beckham @ 2003-03-04 18:56 UTC (permalink / raw)
  To: Netfilter

[-- Attachment #1: Type: text/plain, Size: 10106 bytes --]

No.. just 10base-T 10 and 100.

Daniel
  ----- Original Message ----- 
  From: Steve Reynolds 
  To: Daniel Beckham 
  Sent: Tuesday, March 04, 2003 12:00 PM
  Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

  dumb question. is there any token ring in your network at all.
  thanks
  steve

  Daniel Beckham wrote:

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.

To answer your questions, here is the interface setup on the firewall.

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

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.

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

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.

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.

This is driving me crazy. =)

Daniel Beckham
dealnews.com

----- Original Message -----
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Tuesday, March 04, 2003 10:32 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
check out

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"         |
|        |          <danbeck-netfilter@dealne|
|        |          ws.com>                  |
|        |          Sent by:                 |
|        |          netfilter-admin@lists.net|
|        |          filter.org               |
|        |                                   |
|        |                                   |
|        |          04/03/2003 15:29         |
|        |                                   |
|--------+----------------------------------->

---------------------------------------------------------------------------

----------------------------------------------|

  |

|

  |       To:     "Netfilter" <netfilter@lists.netfilter.org>

|

  |       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. =)

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" <pavang@techknowledge.ws>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
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 <danbeck-netfilter@dealnews.com>
To: <netfilter@lists.netfilter.org>
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

[-- Attachment #2: Type: text/html, Size: 16334 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

[parent not found: <3E64FD61.50107@sqlcomp.com>]

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found]       ` <3E64FD61.50107@sqlcomp.com>
@ 2003-03-04 20:49         ` Daniel Beckham
  2003-03-04 21:12         ` Daniel Beckham
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Beckham @ 2003-03-04 20:49 UTC (permalink / raw)
  To: Netfilter

[-- Attachment #1: Type: text/plain, Size: 10562 bytes --]

Arrrgh, I take it you don't have any help for me then. =)

Daniel

  ----- Original Message ----- 
  From: Steve Reynolds 
  To: Daniel Beckham 
  Sent: Tuesday, March 04, 2003 1:24 PM
  Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

  I saw framing problems similar to what you were seeing last year.  really weird.
  thanks
  steve

  Daniel Beckham wrote:

    No.. just 10base-T 10 and 100.

    Daniel
      ----- Original Message ----- 
      From: Steve Reynolds 
      To: Daniel Beckham 
      Sent: Tuesday, March 04, 2003 12:00 PM
      Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

      dumb question. is there any token ring in your network at all.
      thanks
      steve

      Daniel Beckham wrote:

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.

To answer your questions, here is the interface setup on the firewall.

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

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.

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

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.

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.

This is driving me crazy. =)

Daniel Beckham
dealnews.com

----- Original Message -----
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Tuesday, March 04, 2003 10:32 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
check out

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"         |
|        |          <danbeck-netfilter@dealne|
|        |          ws.com>                  |
|        |          Sent by:                 |
|        |          netfilter-admin@lists.net|
|        |          filter.org               |
|        |                                   |
|        |                                   |
|        |          04/03/2003 15:29         |
|        |                                   |
|--------+----------------------------------->

---------------------------------------------------------------------------

----------------------------------------------|

  |

|

  |       To:     "Netfilter" <netfilter@lists.netfilter.org>

|

  |       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. =)

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" <pavang@techknowledge.ws>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
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 <danbeck-netfilter@dealnews.com>
To: <netfilter@lists.netfilter.org>
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

[-- Attachment #2: Type: text/html, Size: 18155 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found]       ` <3E64FD61.50107@sqlcomp.com>
  2003-03-04 20:49         ` Daniel Beckham
@ 2003-03-04 21:12         ` Daniel Beckham
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Beckham @ 2003-03-04 21:12 UTC (permalink / raw)
  To: Netfilter

[-- Attachment #1: Type: text/plain, Size: 10562 bytes --]

Arrrgh, I take it you don't have any help for me then. =)

Daniel

  ----- Original Message ----- 
  From: Steve Reynolds 
  To: Daniel Beckham 
  Sent: Tuesday, March 04, 2003 1:24 PM
  Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

  I saw framing problems similar to what you were seeing last year.  really weird.
  thanks
  steve

  Daniel Beckham wrote:

    No.. just 10base-T 10 and 100.

    Daniel
      ----- Original Message ----- 
      From: Steve Reynolds 
      To: Daniel Beckham 
      Sent: Tuesday, March 04, 2003 12:00 PM
      Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out

      dumb question. is there any token ring in your network at all.
      thanks
      steve

      Daniel Beckham wrote:

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.

To answer your questions, here is the interface setup on the firewall.

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

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.

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

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.

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.

This is driving me crazy. =)

Daniel Beckham
dealnews.com

----- Original Message -----
From: <richardo@start-global.com>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
Sent: Tuesday, March 04, 2003 10:32 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
check out

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"         |
|        |          <danbeck-netfilter@dealne|
|        |          ws.com>                  |
|        |          Sent by:                 |
|        |          netfilter-admin@lists.net|
|        |          filter.org               |
|        |                                   |
|        |                                   |
|        |          04/03/2003 15:29         |
|        |                                   |
|--------+----------------------------------->

---------------------------------------------------------------------------

----------------------------------------------|

  |

|

  |       To:     "Netfilter" <netfilter@lists.netfilter.org>

|

  |       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. =)

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" <pavang@techknowledge.ws>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
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 <danbeck-netfilter@dealnews.com>
To: <netfilter@lists.netfilter.org>
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

[-- Attachment #2: Type: text/html, Size: 18168 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
@ 2003-03-03 22:23 Daniel Beckham
       [not found] ` <009f01c2e215$69c78830$e11310ac@techknowledge.ws>
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Beckham @ 2003-03-03 22:23 UTC (permalink / raw)
  To: netfilter

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

[parent not found: <009f01c2e215$69c78830$e11310ac@techknowledge.ws>]

* Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out
       [not found] ` <009f01c2e215$69c78830$e11310ac@techknowledge.ws>
@ 2003-03-04 15:29   ` Daniel Beckham
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Beckham @ 2003-03-04 15:29 UTC (permalink / raw)
  To: Netfilter

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. =)

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" <pavang@techknowledge.ws>
To: "Daniel Beckham" <danbeck-netfilter@dealnews.com>
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 <danbeck-netfilter@dealnews.com>
> To: <netfilter@lists.netfilter.org>
> 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
> >
> >
> >
> >
>
>





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2003-03-05 16:38 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <OFB7840FE4.C0F00E27-ON80256CE0.0031E466@start-global.com>
2003-03-05 16:31 ` DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out Daniel Beckham
2003-03-05 16:38 ` Daniel Beckham
     [not found] <OF3A1E747D.4950DEAF-ON80256CDF.005A4395@start-global.com>
2003-03-04 17:26 ` Daniel Beckham
     [not found]   ` <3E64E9A4.6010008@sqlcomp.com>
2003-03-04 18:56     ` Daniel Beckham
     [not found]       ` <3E64FD61.50107@sqlcomp.com>
2003-03-04 20:49         ` Daniel Beckham
2003-03-04 21:12         ` Daniel Beckham
2003-03-03 22:23 Daniel Beckham
     [not found] ` <009f01c2e215$69c78830$e11310ac@techknowledge.ws>
2003-03-04 15:29   ` Daniel Beckham

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox