headers
discussion-request | 8 Sep 10:19
Favicon

[pfSense] Journal

> We're moving both the original mailing lists, and consolidating
Command We're not recognised.

> support@ and discussion@ into this one here at list <at> lists.pfsense.org.
Command support@ not recognised.

> The final message will come through on the old list shortly after
Command The not recognised.

> this. The old two lists were created before the forum existed, when
Command this. not recognised.

> the combined mailing list volume was 4-5 times what it's been since
Command the not recognised.

> then as the bulk of traffic moved and has stayed there, so splitting
Command then not recognised.

> up the lists isn't needed.
Command up not recognised.

> All the addresses that were subscribed to the old lists are subscribed
Command All not recognised.

> to this list. You can still post from the same address you previously
Command to not recognised.

> used.
Command used. not recognised.
(Continue reading)

Permalink | Reply | 55 comments |
headers
Chris Buechler | 8 Sep 09:59
Picon

HEADS UP: this mailing list has moved

The mailing list has moved to list <at> lists.pfsense.org. This list server
is being decommissioned. Your email address on this list has been
subscribed to the new list, and you will receive a welcome message on
that list shortly.

The old support@ and discussion@ emails will bounce. Feel free to
continue existing threads, but you'll have to change the to address to
list <at> lists.pfsense.org.

Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 0 comments |
headers
Odette Nsaka | 25 Aug 22:00
Picon
Favicon

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:<user <at> domain> SIZE=86045 | RCPT TO:<user <at> domain> | DATA
226996 684.552697 MyMailRelayIp -> ProviderMtaIp SMTP S: 250 user <at> domain Sender OK | 250 user <at> domain Recipient OK | 354 Enter message, end with "." on a line by itself
227503 686.321903 MyMailRelayIp -> ProviderMtaIp SMTP [TCP Retransmission] S: 250 user <at> domain Sender OK | 250 user <at> 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 <at> domain> SIZE=56892 | RCPT TO:<user <at> domain> | DATA
19378  46.960259 MyMailRelayIp -> ProviderMtaIp SMTP S: 250 user <at> domain Sender OK | 250 user <at> 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 <at> 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
  


Permalink | Reply | 4 comments |
headers
Odette Nsaka | 25 Aug 18:20
Picon
Favicon

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 <odette.nsaka <at> libero.it>
Permalink | Reply | 1 comment |
headers
Odhiambo Washington | 18 Aug 12:58
Picon

WiFi Hotspot

Hello securetypes,

As I continue falling in love with pfSense, it appears my needs start to increase.

Please give me some pointers on how I can use pfSense as a WiFi Hotspot.

I am hoping that someone has done it already.


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

Permalink | Reply | 0 comments |
headers
Boris Kochergin | 7 Aug 21:42

Lack of camcontrol(8) program

Hi.

I installed the 2.0-RC3 snapshot a few days ago and noticed the absence 
of camcontrol(8). I believe it should be included since the introduction 
of geom_mirror support into the system, because it is required to scan 
SCSI and SAS buses for new disks. Without it, a geom_mirror array cannot 
be rebuilt without the machine being rebooted because no mechanism 
exists to find replacement disks connected to the system.

-Boris

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 0 comments |
headers
Eugen Leitl | 28 Jun 17:29

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

----- Forwarded message from Andreas Ott <andreas <at> naund.org> -----

From: Andreas Ott <andreas <at> naund.org>
Date: Tue, 28 Jun 2011 08:23:46 -0700
To: Eugen Leitl <eugen <at> leitl.org>, williamejsalt <at> googlemail.com
Cc: NANOG list <nanog <at> nanog.org>
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
User-Agent: Mutt/1.2.5.1i

Hi,

On Tue, Jun 28, 2011 at 10:52:55AM +0200, Eugen Leitl wrote:
> ----- Forwarded message from William Salt <williamejsalt <at> googlemail.com> -----
> From: William Salt <williamejsalt <at> googlemail.com>
> Date: Tue, 28 Jun 2011 08:03:25 +0100
> To: support <at> pfsense.com
> Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
> Reply-To: support <at> pfsense.com

> Each TCP connection starts very slowly, and will max out at around 190mbps,
> taking nearly 2 minutes to climb to this speed before *plateauing*.
> 
> We have to initiate many (5+) connections to saturate the link with tcp
> connections with iperf.
> ----- End forwarded message -----

You pretty much solved your own puzzle right there: the throughput on a
single TCP connection will max out at the value determined by the bandwidth 
delay product (excluding other strange conditions, such as deep buffers).

Here is a calculator online:
http://www.switch.ch/network/tools/tcp_throughput/

-andreas
[who has to explain this about once a week to customers who think
that they bought a GigE connection but then can't "ftp" a file from
coast to coast at 1Gbps throughput. Use multiple TCP streams!]

----- End forwarded message -----
--

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 2 comments |
headers
Eugen Leitl | 18 Jun 13:43

package reinstall hangs


Just upgraded to latest, 2.0-RC1-IPv6 (i386)
built on Fri Jun 17 22:47:41 EDT 2011 and package
reinstallation screen doesn't seem to want to go away.

Any way to purge the packages, or trigger reinstallation?

--

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 2 comments |
headers
Alfred Nagl | 16 Jun 12:13
Picon
Favicon

Re: confirm unsubscribe from discussion <at> pfsense.com

On Thursday 16 June 2011, discussion-help <at> pfsense.com wrote:
> Hi! This is the ezmlm program. I'm managing the
> discussion <at> pfsense.com mailing list.
> 
> I'm working for my owner, who can be reached
> at discussion-owner <at> pfsense.com.
> 
> To confirm that you would like
> 
>    nagl <at> wu.ac.at
> 
> removed from the discussion mailing list, please send an empty reply
> to this address:
> 
>    discussion-uc.1308218201.jkcdplibfikkhmnbmlkp-nagl=wu.ac.at <at> pfsense.com
> 
> Usually, this happens when you just hit the "reply" button.
> If this does not work, simply copy the address and paste it into
> the "To:" field of a new message.
> 
> I haven't checked whether your address is currently on the mailing list.
> To see what address you used to subscribe, look at the messages you are
> receiving from the mailing list. Each message has your address hidden
> inside its return path; for example, mary <at> xdd.ff.com receives messages
> with return path: <discussion-return-≤number>-mary=xdd.ff.com <at> pfsense.com.
> 
> Some mail programs are broken and cannot handle long addresses. If you
> cannot reply to this request, instead send a message to
> <discussion-request <at> pfsense.com> and put the entire address listed above
> into the "Subject:" line.
> 
> 
> --- Administrative commands for the discussion list ---
> 
> I can handle administrative requests automatically. Please
> do not send them to the list address! Instead, send
> your message to the correct command address:
> 
> For help and a description of available commands, send a message to:
>    <discussion-help <at> pfsense.com>
> 
> To subscribe to the list, send a message to:
>    <discussion-subscribe <at> pfsense.com>
> 
> To remove your address from the list, just send a message to
> the address in the ``List-Unsubscribe'' header of any list
> message. If you haven't changed addresses since subscribing,
> you can also send a message to:
>    <discussion-unsubscribe <at> pfsense.com>
> 
> For addition or removal of addresses, I'll send a confirmation
> message to that address. When you receive it, simply reply to it
> to complete the transaction.
> 
> If you need to get in touch with the human owner of this list,
> please send a message to:
> 
>     <discussion-owner <at> pfsense.com>
> 
> Please include a FORWARDED list message with ALL HEADERS intact
> to make it easier to help you.
> 
> --- Enclosed is a copy of the request I received.
> 
> Return-Path: <nagl <at> wu.ac.at>
> Received: (qmail 91586 invoked by uid 89); 16 Jun 2011 09:56:41 -0000
> Received: from unknown (HELO williams.wu-wien.ac.at) (137.208.8.38)
>   by 172.29.29.14 with SMTP; 16 Jun 2011 09:56:41 -0000
> Received: from groko.localnet (groko.wu-wien.ac.at [137.208.4.8])
> 	(authenticated bits=0)
> 	by williams.wu-wien.ac.at (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id
> p5G9ucCE014814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
> verify=NO) for <discussion-unsubscribe <at> pfsense.com>; Thu, 16 Jun 2011
> 11:56:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=wu.ac.at;
> 	s=sslmail2009; t=1308218200; bh=SfL4Gxl7dF0FyplyT9nM/k+c46DgZ8Xn9Qh
> 	XP6/5u7U=; h=From:To:Date:MIME-Version:Content-Type:
> 	 Content-Transfer-Encoding:Message-Id; b=pqEUoSHNWAeK3GQBO+bOJ/tQgB
> 	cMW/1MiVIVCmPRnKd38hu+mePROwCoYW+E3x0yaJpsEXwAFsRuWaGL6hB4kcmilJ2pd
> 	6JHV5mkfRKEQ8WGSTpue9rTryEX6Fbz/B5srCRSsBuuOtZyF7b9w6WduTyEyJEG54mY
> 	q5f63L1423M=
> From: Alfred Nagl <nagl <at> wu.ac.at>
> Organization: WU
> To: discussion-unsubscribe <at> pfsense.com
> Date: Thu, 16 Jun 2011 11:56:38 +0200
> User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; )
> MIME-Version: 1.0
> Content-Type: Text/Plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Message-Id: <201106161156.38566.nagl <at> wu.ac.at>
> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.5.20; VDF:
> 7.11.9.232; host: herpes); id=3311-NmGp8I X-Virus-Scanned: clamav-milter
> 0.96.1 at pocken
> X-Virus-Status: Clean
> 
> 
> =2D-=20
> Alfred Nagl
> IT-Services / Network Administration
> 
> WU=20
> Wirtschaftsuniversit=C3=A4t Wien
> Vienna University of Economics and Business=20
> Augasse 2-6, A-1090 Vienna, Austria
> 
> Phone: +43 1 313 36 / 4811
> =46ax:   +43 1 313 36 / 904811

--

-- 
Alfred Nagl
IT-Services / Network Administration

WU 
Wirtschaftsuniversität Wien
Vienna University of Economics and Business 
Augasse 2-6, A-1090 Vienna, Austria

Phone: +43 1 313 36 / 4811
Fax:   +43 1 313 36 / 904811

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 0 comments |
headers
Odhiambo Washington | 8 Jun 19:50
Picon

Disk-based Backup

I have decided that my pfSense PC will have two disks - ad4 and ad6 as they are now.
I'd like to backup ad4 to ad6 every weekend - automated using dump.

Is this the stupid way of doing it?

I have a feeling that someone would tell me that, but imagine if the disk crashed and I wanted to be up and running without being at the site. I could simply tell someone to open the box and interchange the SATA data cables, then power back on.

I did try mounting the 2nd disk but it wouldn't allow me. So I am left with dd as the only option to do the disk backup:)

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

Permalink | Reply | 6 comments |
headers
Eugen Leitl | 8 Jun 15:40

happy IPv6 day


This being the World IPv6 day, I enabled IPv6 on three pfSense
instances, using the excellent http://iserv.nl/files/pfsense/ipv6/
(thanks, Seth!) without problems.

--

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

---------------------------------------------------------------------
To unsubscribe, e-mail: discussion-unsubscribe <at> pfsense.com
For additional commands, e-mail: discussion-help <at> pfsense.com

Commercial support available - https://portal.pfsense.org
Permalink | Reply | 2 comments |

Gmane