[pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino
It's a lot of time I'm using PF and I really appreciate it. The guys are doing a very good job. I'm successfully using PF 2.0-RC3, even on Alix (embedded) an installed on PC, with ipsec vpn, OVPN, carp for failover, WAN in load balancing on 2 diffrent 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 is filtered fine out of the SMTP traffic from the e-mail provider to the internal MailReley server. Reverting to 1.2.3 it works fine again. An inspetction to the traffic made through a mirror port on the switch shows the different behaviours reported below Hrere are the anonimized data sniffed with related to -- Odette Nsaka
Re: [pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino
Sorry, a finger dropped on the wrong button and message have been sent before completing... I'm editing the correct one and going to post it ASAP. Odette Il giorno gio, 25/08/2011 alle 18.20 +0200, Odette Nsaka ha scritto: > It's a lot of time I'm using PF and I really appreciate it. The guys > are doing a very good job. > > I'm successfully using PF 2.0-RC3, even on Alix (embedded) an > installed on PC, with ipsec vpn, OVPN, carp for failover, WAN in load > balancing on 2 diffrent 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 is filtered fine > out of the SMTP traffic from the e-mail provider to the internal > MailReley server. Reverting to 1.2.3 it works fine again. > > An inspetction to the traffic made through a mirror port on the switch > shows the different behaviours reported below > > Hrere are the anonimized data sniffed with related to > > > > > -- > Odette Nsaka -- Odette Nsaka
[pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino
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: SIZE=86045 | RCPT TO: | 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: SIZE=56892 | RCPT TO: | 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 1939
Re: [pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino
Could u pls guide me how i configure open vpn.. On 8/26/11, Odette Nsaka 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: SIZE=86045 | RCPT TO: | 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: SIZE=56892 | RCPT TO: | 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, 124
