[prev in list] [next in list] [prev in thread] [next in thread]
List: pfsense-discussion
Subject: [pfSense-discussion] OpenVPN setup
From: Odette Nsaka <odette.nsaka () libero ! it>
Date: 2011-08-26 10:50:46
Message-ID: 1314355846.3129.71.camel () boion
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Subject changed from
Re: [pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus
Domino
because of changed topic
I don't have specific personal procedures to do that. To configure
openVPN on PF I generally use as guidelines the following docs
For a Site-to-Site OVPN
based on pre-shared keys (suggested in case of a single OVPN
server set up as the "hub", and one or few OVPN clients that
connect to the server)
for PF 1.2.3:
http://doc.pfsense.org/index.php/OpenVPN_Site_To_Site
for PF 2.0:
http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_%
28Shared_Key,_2.0%29
based on SSL certificates, suggested when you have one OVPN
server (e.g. Central office) and many OVPN clients (remote
sites)
in both the previous documents follow the link to
http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29
For road warrior OVPN you can follow a well done guide at
http://blog.stefcho.eu/?p=492
And then, if something doesn't work, looking at the logs I try to find
what's wrong and correct it.
Some hints:
* "Tunnel Network" the OVPN server configuration page have to be
(private and) different from local and remote reachable existing
networks
* If you need to force the remote peer or road warrior client to
route a specific network destination (e.g. 192.168.110.0/24)
through the OVPN tunnel, you can push the route from the server
to the client. In the OVPN server configuration page of the OVPN
server, in advanced configuration, add:
push "route 192.168.110.0 255.255.255.0";
So, if following the suggested documentation OVPN will not work, or if
you have other questions, I'll be pleased to answer.
Odette
--
Odette Nsaka <odette.nsaka@libero.it>
Il giorno ven, 26/08/2011 alle 12.36 +0300, Odhiambo Washington ha
scritto:
> Odette,
>
> If you could churn out a tutorial based on pfSense 2.0 for both
> site-to-site and road warrior, I believe it will be a great resource
> for us.
>
>
>
> On Fri, Aug 26, 2011 at 12:30, Odette Nsaka <odette.nsaka@libero.it>
> wrote:
>
> Which kind of OVPN: site to site or road warrior? With PF
> 1.2.2 or 2.0?
> --
> Odette Nsaka <odette.nsaka@libero.it>
>
>
> Il giorno ven, 26/08/2011 alle 10.29 +0530, A Mohan Rao ha
> scritto:
>
>
> > Could u pls guide me how i configure open vpn..
> >
> > On 8/26/11, Odette Nsaka <odette.nsaka@libero.it> wrote:
> > > It's a lot of time I'm using PF and I really appreciate it. Guys
> > > you are doing a very good job.
> > >
> > > I'm successfully using PF 2.0-RC3, even on Alix (embedded) and
> > > installed on PC, with ipsec vpn, OVPN, carp for failover, WiFi, WAN in
> > > load
> > > balancing on 2 different ADSL lines, etc. Everything is working really
> > > fine.
> > >
> > > But a few days ago I encountered a problem that I cannot understand and
> > > resolve: I've been upgrading a couple of PF installed on pc (configured
> > > in failover with CARP, 5 nics) from release 1.2.3 to 2.0-RC3.
> > >
> > > In version 1.2.3 and all the previous updates have everything been
> > > working fine.
> > >
> > > After the upgrade to 2.0-RC3 I had just one problem, but because of
> > > this I had to revert to 1.2.3.
> > >
> > > Here is the problem.
> > >
> > > After the upgrade to version 2.0-RC3 every protocol has been filtered
> > > by PF as expected. But the SMTP traffic from the e-mail provider mta
> > > (postfix) to the internal MailReley server had a strange behaviour. On
> > > the internal mail relay I saw the connection estabilished from the
> > > provider mta, but at the moment of receiving the the mail body the
> > > connection hanged up and reset at timeout. Just small e-mails, sent as
> > > a test by the provider, have been successfully delivered.
> > >
> > > Reverting to 1.2.3 everything works fine again.
> > >
> > > An inspection to the traffic, made through a mirror port on the switch
> > > (verified sniffing directly on PF)
> > > shows the different behaviours reported below.
> > >
> > > Here are the data captured with 2.0-RC3, related to an attempt of the
> > > MTA to send an e-mail messages to the internal mail relay.
> > >
> > >
> > > 226970 684.515289 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > > smtp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=68980421 TSER=0
> > > WS=7
> > > 226971 684.515768 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> > > 57715 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0
> > > TSER=0
> > > 226973 684.526527 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=68980427 TSER=0
> > > 226977 684.529562 MyMailRelayIp -> ProviderMtaIp SMTP S: 220
> > > mail.mycompany.com ESMTP Service (Lotus Domino Release 8.5.1FP2)
> > > ready at Wed, 27 Jul 2011 12:52:04 +0200
> > > 226978 684.537048 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > > smtp [ACK] Seq=1 Ack=110 Win=5888 Len=0 TSV=68980443 TSER=625882
> > > 226979 684.537070 ProviderMtaIp -> MyMailRelayIp SMTP C: EHLO
> > > fedora.provider.org
> > > 226980 684.537868 MyMailRelayIp -> ProviderMtaIp SMTP S:
> > > 250-mail.mycompany.com Hello fedora.provider.org
> > > ([ProviderMtaIp]), pleased to meet you | 250-TLS | 250-ETRN |
> > > 250-STARTTLS | 250-DSN | 250-SIZE 18432000 | 250 PIPELINING
> > > 226992 684.551654 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> > > FROM:<user@domain> SIZE=86045 | RCPT TO:<user@domain> | DATA
> > > 226996 684.552697 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > > user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> > > message, end with "." on a line by itself
> > > 227503 686.321903 MyMailRelayIp -> ProviderMtaIp SMTP [TCP
> > > Retransmission] S: 250 user@domain Sender OK | 250 user@domain
> > > Recipient OK | 354 Enter message, end with "." on a line by
> > > itself
> > > 227505 686.329892 ProviderMtaIp -> MyMailRelayIp TCP [TCP
> > > Previous segment lost] 57715 > smtp [ACK] Seq=3001 Ack=404
> > > Win=8064 Len=0 TSV=68982235 TSER=625901 SLE=274 SRE=404
> > > 343904 1013.873824 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> > > 57715 [FIN, ACK] Seq=404 Ack=105 Win=64136 Len=0 TSV=629175
> > > TSER=68980454
> > > 343909 1013.883338 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > > smtp [RST] Seq=105 Win=0 Len=0
> > >
> > >
> > > As I can see the traffic between the provider's MTA and the mai relay
> > > starts and, initially it goes on, but packet ID 226996 get lost, then
> > > retransmitted (227503) and acknowledged by ProviderMtaIp but with a
> > > grater Seq. number. It looks like the mail data packets have been lost.
> > > Then, after about 5 min. the connection reaches the time out, mail
> > > relay sends a FIN request and the ProviderMtaIp resets the connection.
> > >
> > > On PF's logs there's nothing about dropped packets related to the
> > > connection.
> > >
> > >
> > >
> > > Here's, what happens reverting to 1.2.3 (everything works fine).
> > >
> > > ...
> > > 19377 46.958958 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> > > FROM:<user@domain> SIZE=56892 | RCPT TO:<user@domain> | DATA
> > > 19378 46.960259 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > > user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> > > message, end with "." on a line by itself
> > > 19386 46.971715 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19387 46.974048 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19388 46.974082 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19389 46.974425 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=420 Ack=2617 Win=64240 Len=0 TSV=706364 TSER=77029773
> > > 19393 46.987139 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19394 46.987663 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=420 Ack=5113 Win=63248 Len=0 TSV=706365 TSER=77029773
> > > 19395 46.987686 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> > > 19394#1] smtp > 33359 [ACK] Seq=420 Ack=5113 Win=63248 Len=0
> > > TSV=706365 TSER=77029773
> > > 19396 46.989640 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19397 46.989661 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19398 46.990342 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=420 Ack=7609 Win=64240 Len=0 TSV=706365 TSER=77029787
> > > 19407 46.999000 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19408 46.999026 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > ...
> > > 19492 47.067918 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19493 47.068921 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19494 47.069291 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=420 Ack=54809 Win=64240 Len=0 TSV=706365 TSER=77029856
> > > 19495 47.070644 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > > fragment, 1248 bytes
> > > 19507 47.078352 ProviderMtaIp -> MyMailRelayIp IMF from: "user"
> > > <user@domain>, subject xxx Masked Subject xxx, (text/plain)
> > > (text/html)
> > > 19508 47.078846 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=420 Ack=57023 Win=63530 Len=0 TSV=706365 TSER=77029856
> > > 19509 47.078867 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> > > 19508#1] smtp > 33359 [ACK] Seq=420 Ack=57023 Win=63530 Len=0
> > > TSV=706365 TSER=77029856
> > > 19517 47.084957 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > > Message accepted for delivery
> > > 19518 47.085306 MyMailRelayIp -> ProviderMtaIp SMTP S: 221
> > > mail.mycompany.com SMTP Service closing transmission channel
> > > 19519 47.085405 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [FIN, ACK] Seq=519 Ack=57023 Win=63530 Len=0 TSV=706365
> > > TSER=77029856
> > > 19527 47.096111 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> > > [FIN, ACK] Seq=57023 Ack=519 Win=8064 Len=0 TSV=77029898
> > > TSER=706365
> > > 19528 47.096609 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > > [ACK] Seq=520 Ack=57024 Win=63530 Len=0 TSV=706366 TSER=77029898
> > > 19529 47.098002 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> > > [ACK] Seq=57024 Ack=520 Win=8064 Len=0 TSV=77029900 TSER=706365
> > >
> > >
> > >
> > >
> > > I've also tried to play around with the MTU value, with no effect.
> > >
> > > Mail Relay is Lotus Domino Release 8.5.1FP2 and the mta is
> > > Fedora, kernel 2.6.18-1, server postfix 2.2.8-1.2
> > > During the tests the provider also tried Debian, kernel 2.6.26-2, server
> > > postfix 2.5.5-1.1
> > >
> > > The provider's mta lies in internet (WAN side of the PF), while the the
> > > mail relay is in one of the DMZs of the PF, with public IP, no nat.
> > > Even WAN and DMZ are over CARP for fault tolerance.
> > >
> > > The provider have been delivering the e-mails to all other customers,
> > > with no problem, and asserts that all his servers are strictly compliant
> > > the RFCs
> > > The router connecting to Internet is set up with MTU=1476.
> > >
> > > Please, does someone have an idea of what is going on, or did already
> > > see a similar behaviour?
> > > Every suggestion will be appreciated.
> > >
> > > Thank you in advance.
> > >
> > > Odette Nsaka
> > >
> > >
> > >
> > >
> >
>
>
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I can't hear you -- I'm using the scrambler.
> Please consider the environment before printing this email.
>
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
Subject changed from<BR>
<BLOCKQUOTE>
Re: [pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino<BR>
</BLOCKQUOTE>
because of changed topic<BR>
<BR>
I don't have specific personal procedures to do that. To configure openVPN on PF I \
generally use as guidelines the following docs<BR> <BR>
For a Site-to-Site OVPN<BR>
<BLOCKQUOTE>
based on pre-shared keys (suggested in case of a single OVPN server set up as the \
"hub", and one or few OVPN clients that connect to the \
server)<BR> <BLOCKQUOTE>
for PF 1.2.3: <A \
HREF="http://doc.pfsense.org/index.php/OpenVPN_Site_To_Site">http://doc.pfsense.org/index.php/OpenVPN_Site_To_Site</A><BR>
for PF 2.0: <A \
HREF="http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_%28Shared_Key,_2.0%29">http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_%28Shared_Key,_2.0%29</A><BR>
</BLOCKQUOTE>
based on SSL certificates, suggested when you have one OVPN server (e.g. Central \
office) and many OVPN clients (remote sites) <BR> <BLOCKQUOTE>
in both the previous documents follow the link to <A \
HREF="http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29">http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29</A><BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
For road warrior OVPN you can follow a well done guide at<BR>
<BLOCKQUOTE>
<A HREF="http://blog.stefcho.eu/?p=492">http://blog.stefcho.eu/?p=492</A><BR>
</BLOCKQUOTE>
<BR>
And then, if something doesn't work, looking at the logs I try to find what's wrong \
and correct it.<BR> <BR>
Some hints:
<UL>
<LI>"Tunnel Network" the OVPN server configuration page have to be \
(private and) different from local and remote reachable existing networks <LI>If you \
need to force the remote peer or road warrior client to route a specific network \
destination (e.g. 192.168.110.0/24) through the OVPN tunnel, you can push the \
route from the server to the client. In the OVPN server configuration page of the \
OVPN server, in advanced configuration, add: </UL>
<BLOCKQUOTE>
<BLOCKQUOTE>
push "route 192.168.110.0 255.255.255.0";<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
So, if following the suggested documentation OVPN will not work, or if you have other \
questions, I'll be pleased to answer.<BR> <BR>
Odette<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Odette Nsaka <<A HREF="mailto:odette.nsaka@libero.it">odette.nsaka@libero.it</A>><BR>
<BR>
</TD>
</TR>
</TABLE>
Il giorno ven, 26/08/2011 alle 12.36 +0300, Odhiambo Washington ha scritto:<BR>
<BLOCKQUOTE TYPE=CITE>
Odette,<BR>
<BR>
If you could churn out a tutorial based on pfSense 2.0 for both site-to-site and \
road warrior, I believe it will be a great resource for us.<BR> <BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On Fri, Aug 26, 2011 at 12:30, Odette Nsaka <<A \
HREF="mailto:odette.nsaka@libero.it">odette.nsaka@libero.it</A>> wrote: \
</BLOCKQUOTE> <BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Which kind of OVPN: site to site or road warrior? With PF 1.2.2 or 2.0?<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
--
Odette Nsaka <<A HREF="mailto:odette.nsaka@libero.it">odette.nsaka@libero.it</A>><BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
Il giorno ven, 26/08/2011 alle 10.29 +0530, A Mohan Rao ha scritto:
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Could u pls guide me how i configure open vpn..
On 8/26/11, Odette Nsaka <<A \
HREF="mailto:odette.nsaka@libero.it">odette.nsaka@libero.it</A>> wrote: > It's \
a lot of time I'm using PF and I really appreciate it. Guys > you are doing a very \
good job. >
> I'm successfully using PF 2.0-RC3, even on Alix (embedded) and
> installed on PC, with ipsec vpn, OVPN, carp for failover, WiFi, WAN in
> load
> balancing on 2 different ADSL lines, etc. Everything is working really
> fine.
>
> But a few days ago I encountered a problem that I cannot understand and
> resolve: I've been upgrading a couple of PF installed on pc (configured
> in failover with CARP, 5 nics) from release 1.2.3 to 2.0-RC3.
>
> In version 1.2.3 and all the previous updates have everything been
> working fine.
>
> After the upgrade to 2.0-RC3 I had just one problem, but because of
> this I had to revert to 1.2.3.
>
> Here is the problem.
>
> After the upgrade to version 2.0-RC3 every protocol has been filtered
> by PF as expected. But the SMTP traffic from the e-mail provider mta
> (postfix) to the internal MailReley server had a strange behaviour. On
> the internal mail relay I saw the connection estabilished from the
> provider mta, but at the moment of receiving the the mail body the
> connection hanged up and reset at timeout. Just small e-mails, sent as
> a test by the provider, have been successfully delivered.
>
> Reverting to 1.2.3 everything works fine again.
>
> An inspection to the traffic, made through a mirror port on the switch
> (verified sniffing directly on PF)
> shows the different behaviours reported below.
>
> Here are the data captured with 2.0-RC3, related to an attempt of the
> MTA to send an e-mail messages to the internal mail relay.
>
>
> 226970 684.515289 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=68980421 TSER=0
> WS=7
> 226971 684.515768 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> 57715 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0
> TSER=0
> 226973 684.526527 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=68980427 TSER=0
> 226977 684.529562 MyMailRelayIp -> ProviderMtaIp SMTP S: 220
> <A HREF="http://mail.mycompany.com">mail.mycompany.com</A> ESMTP Service \
(Lotus Domino Release 8.5.1FP2) > ready at Wed, 27 Jul 2011 12:52:04 +0200
> 226978 684.537048 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [ACK] Seq=1 Ack=110 Win=5888 Len=0 TSV=68980443 TSER=625882
> 226979 684.537070 ProviderMtaIp -> MyMailRelayIp SMTP C: EHLO
> <A HREF="http://fedora.provider.org">fedora.provider.org</A>
> 226980 684.537868 MyMailRelayIp -> ProviderMtaIp SMTP S:
> <A HREF="http://250-mail.mycompany.com">250-mail.mycompany.com</A> Hello \
<A HREF="http://fedora.provider.org">fedora.provider.org</A> > \
([ProviderMtaIp]), pleased to meet you | 250-TLS | 250-ETRN | > \
250-STARTTLS | 250-DSN | 250-SIZE 18432000 | 250 PIPELINING > 226992 \
684.551654 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL > \
FROM:<user@domain> SIZE=86045 | RCPT TO:<user@domain> | DATA > \
226996 684.552697 MyMailRelayIp -> ProviderMtaIp SMTP S: 250 > \
user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter > \
message, end with "." on a line by itself > 227503 686.321903 \
MyMailRelayIp -> ProviderMtaIp SMTP [TCP > Retransmission] S: 250 \
user@domain Sender OK | 250 user@domain > Recipient OK | 354 Enter \
message, end with "." on a line by > itself
> 227505 686.329892 ProviderMtaIp -> MyMailRelayIp TCP [TCP
> Previous segment lost] 57715 > smtp [ACK] Seq=3001 Ack=404
> Win=8064 Len=0 TSV=68982235 TSER=625901 SLE=274 SRE=404
> 343904 1013.873824 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> 57715 [FIN, ACK] Seq=404 Ack=105 Win=64136 Len=0 TSV=629175
> TSER=68980454
> 343909 1013.883338 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [RST] Seq=105 Win=0 Len=0
>
>
> As I can see the traffic between the provider's MTA and the mai relay
> starts and, initially it goes on, but packet ID 226996 get lost, then
> retransmitted (227503) and acknowledged by ProviderMtaIp but with a
> grater Seq. number. It looks like the mail data packets have been lost.
> Then, after about 5 min. the connection reaches the time out, mail
> relay sends a FIN request and the ProviderMtaIp resets the connection.
>
> On PF's logs there's nothing about dropped packets related to the
> connection.
>
>
>
> Here's, what happens reverting to 1.2.3 (everything works fine).
>
> ...
> 19377 46.958958 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> FROM:<user@domain> SIZE=56892 | RCPT TO:<user@domain> | DATA
> 19378 46.960259 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> message, end with "." on a line by itself
> 19386 46.971715 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19387 46.974048 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19388 46.974082 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19389 46.974425 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=2617 Win=64240 Len=0 TSV=706364 TSER=77029773
> 19393 46.987139 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19394 46.987663 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=5113 Win=63248 Len=0 TSV=706365 TSER=77029773
> 19395 46.987686 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> 19394#1] smtp > 33359 [ACK] Seq=420 Ack=5113 Win=63248 Len=0
> TSV=706365 TSER=77029773
> 19396 46.989640 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19397 46.989661 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19398 46.990342 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=7609 Win=64240 Len=0 TSV=706365 TSER=77029787
> 19407 46.999000 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19408 46.999026 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> ...
> 19492 47.067918 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19493 47.068921 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19494 47.069291 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=54809 Win=64240 Len=0 TSV=706365 TSER=77029856
> 19495 47.070644 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19507 47.078352 ProviderMtaIp -> MyMailRelayIp IMF from: \
"user" > <user@domain>, subject xxx Masked Subject xxx, \
(text/plain) > (text/html)
> 19508 47.078846 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=57023 Win=63530 Len=0 TSV=706365 TSER=77029856
> 19509 47.078867 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> 19508#1] smtp > 33359 [ACK] Seq=420 Ack=57023 Win=63530 Len=0
> TSV=706365 TSER=77029856
> 19517 47.084957 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> Message accepted for delivery
> 19518 47.085306 MyMailRelayIp -> ProviderMtaIp SMTP S: 221
> <A HREF="http://mail.mycompany.com">mail.mycompany.com</A> SMTP Service \
closing transmission channel > 19519 47.085405 MyMailRelayIp -> \
ProviderMtaIp TCP smtp > 33359 > [FIN, ACK] Seq=519 Ack=57023 Win=63530 \
Len=0 TSV=706365 > TSER=77029856
> 19527 47.096111 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> [FIN, ACK] Seq=57023 Ack=519 Win=8064 Len=0 TSV=77029898
> TSER=706365
> 19528 47.096609 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=520 Ack=57024 Win=63530 Len=0 TSV=706366 TSER=77029898
> 19529 47.098002 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> [ACK] Seq=57024 Ack=520 Win=8064 Len=0 TSV=77029900 TSER=706365
>
>
>
>
> I've also tried to play around with the MTU value, with no effect.
>
> Mail Relay is Lotus Domino Release 8.5.1FP2 and the mta is
> Fedora, kernel 2.6.18-1, server postfix 2.2.8-1.2
> During the tests the provider also tried Debian, kernel 2.6.26-2, server
> postfix 2.5.5-1.1
>
> The provider's mta lies in internet (WAN side of the PF), while the the
> mail relay is in one of the DMZs of the PF, with public IP, no nat.
> Even WAN and DMZ are over CARP for fault tolerance.
>
> The provider have been delivering the e-mails to all other customers,
> with no problem, and asserts that all his servers are strictly compliant
> the RFCs
> The router connecting to Internet is set up with MTU=1476.
>
> Please, does someone have an idea of what is going on, or did already
> see a similar behaviour?
> Every suggestion will be appreciated.
>
> Thank you in advance.
>
> Odette Nsaka
>
>
>
>
</PRE>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
<BR>
-- <BR>
Best regards,<BR>
Odhiambo WASHINGTON,<BR>
Nairobi,KE<BR>
+254733744121/+254722743223<BR>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ <BR>
I can't hear you -- I'm using the scrambler.<BR>
<IMG SRC="cid:image001.png@01CBFF85.F00DA370" WIDTH="35" HEIGHT="33" \
ALIGN="bottom" BORDER="0">Please consider the environment before printing this email. \
<BR> <BR>
</BLOCKQUOTE>
</BODY>
</HTML>
["image001.png" (image/png)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic