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.ns...@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.ns...@libero.it>
> wrote:
>
> Which kind of OVPN: site to site or road warrior? With PF
> 1.2.2 or 2.0?
> --
> Odette Nsaka <odette.ns...@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.ns...@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.
>
<<image001.png>>
