On 2021-11-10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> I'm trying to get synproxy working on a firewall, using the following
> rule:
>
> pass quick proto tcp from any to $front_smtp4 port 25 synproxy state
>
> The firewall accepts the connection on the outside interface, but
> I don't see
Don't know what are you trying to see here, but what that rules does is
simple passing the traffic on any interface to your $front_smtp4 hosts
on port 25, with synproxy.
If you trying to forward traffic from the firewall to your $fornt_smtp4
servers, you are missing stuff.
I'm trying to get synproxy working on a firewall, using the following
rule:
pass quick proto tcp from any to $front_smtp4 port 25 synproxy state
The firewall accepts the connection on the outside interface, but
I don't see (tcpdump) any attempt to complete the connectiom on the
inside
Dear all,
I've setup a pf firewall with synproxy. I've ran a simulated DDoS for a
service behind pf, everything went fine, until I've found that rarely a
tcp connection got established to the service behind pf.
The reason was (due to a configuraion problem) that the firewall actually
was
On cs, aug 16, 2012 at 20:43:18 +0100, Kevin Chadwick wrote:
pass all flags S/SA
pass in on pppoe0 inet proto tcp from src to dst port = flags
S/SA synproxy state
Originally you posted pass in quick. Keep the quick in there, not for
any reason other than I have a quick
Hi!
I'm using 5.1-stable on two machines with pppoe connections. The pf
synproxy state option doesn't work on pppoe interfaces, it just sends
back a TCP reset when trying to connect to a port configured with
synproxy state.
Meanwhile it works on any other interface (eg. the internal LAN
On cs, aug 16, 2012 at 12:19:06 +0200, LEVAI Daniel wrote:
[...]
Forgot the dmesg. If it matters.
OpenBSD 5.1-stable (GENERIC) #0: Tue Aug 7 02:00:34 CEST 2012
root@.:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz (GenuineIntel 686-class) 2.42 GHz
cpu0:
Any help would be appreciated.
Works for me on 5.1
I don't think it's the rule but the combination of rules. Try reordering
your ruleset. I've had a problem before but I forget or never found the
specific reason.
--
___
On cs, aug 16, 2012 at 12:20:56 +0100, Kevin Chadwick wrote:
Any help would be appreciated.
Works for me on 5.1
I don't think it's the rule but the combination of rules. Try reordering
your ruleset. I've had a problem before but I forget or never found the
specific reason.
Okay, okay,
On cs, aug 16, 2012 at 14:26:05 +0200, LEVAI Daniel wrote:
On cs, aug 16, 2012 at 12:20:56 +0100, Kevin Chadwick wrote:
Any help would be appreciated.
Works for me on 5.1
I don't think it's the rule but the combination of rules. Try reordering
your ruleset. I've had a problem
# pfctl -sr
pass all flags S/SA
pass in on pppoe0 inet proto tcp from src to dst port = flags S/SA
synproxy state
This is the only rule. Otherwise it's just 'pass all'. If I remove this
rule too *or* change synproxy to keep, the connection is working.
I remember being puzzled by
On Thu, 16 Aug 2012 14:37:50 +0200
LEVAI Daniel l...@ecentrum.hu wrote:
On cs, aug 16, 2012 at 14:26:05 +0200, LEVAI Daniel wrote:
On cs, aug 16, 2012 at 12:20:56 +0100, Kevin Chadwick wrote:
Any help would be appreciated.
Works for me on 5.1
I don't think it's the rule but
On cs, aug 16, 2012 at 17:18:08 +0200, Christopher Zimmermann wrote:
On Thu, 16 Aug 2012 14:37:50 +0200
LEVAI Daniel l...@ecentrum.hu wrote:
On cs, aug 16, 2012 at 14:26:05 +0200, LEVAI Daniel wrote:
On cs, aug 16, 2012 at 12:20:56 +0100, Kevin Chadwick wrote:
Any help would be
On cs, aug 16, 2012 at 15:10:51 +0100, Kevin Chadwick wrote:
# pfctl -sr
pass all flags S/SA
pass in on pppoe0 inet proto tcp from src to dst port = flags S/SA
synproxy state
This is the only rule. Otherwise it's just 'pass all'. If I remove this
rule too *or* change synproxy
pass all flags S/SA
pass in on pppoe0 inet proto tcp from src to dst port = flags
S/SA synproxy state
Originally you posted pass in quick. Keep the quick in there, not for
any reason other than I have a quick in my rules. Same with the NIC, I
don't have any logical hopes for
On k, júl 24, 2012 at 12:32:19 +0200, hvom .org wrote:
Hi
try : pass in on $ext_if proto tcp to $ext_ip port imap synproxy state
What do you mean? This basically evaluates to the same rule.
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C
Hi!
I've upgraded two 5.0 boxes to 5.1, and noticed that my long standing pf
rules with 'synproxy state' stopped working.
This is an example:
block all
[...]
antispoof quick for $ext_if
[...]
pass in on $ext_if inet proto tcp from any to $ext_ip port imap \
synproxy state \
Hi
try : pass in on $ext_if proto tcp to $ext_ip port imap synproxy state
@plus
2012/7/24 LEVAI Daniel l...@ecentrum.hu
Hi!
I've upgraded two 5.0 boxes to 5.1, and noticed that my long standing pf
rules with 'synproxy state' stopped working.
This is an example:
block all
[...]
On 7/29/10, Ryan McBride mcbr...@openbsd.org wrote:
On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote:
Sadly this means scalability (adding multiple synproxy boxes) is not
possible,
...
synproxy works by completing the 3-way handshake with the source first,
then negotiating a
On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote:
Confirmed - synproxy works great if the synproxy machine is the
default gateway for the end host. Sadly this means scalability (adding
multiple synproxy boxes) is not possible, nor is it possible to filter a
specific IP out of the
* Justin jus...@sk1llz.net [2010-07-29 01:12]:
From what you've
described, the PF synproxy box would literally have to be inline and
the default gateway.
the way you set it up, of course
Is this the case? Would it not be possible to add this
functionality in some way?
if you think about
you have a serious lack of understanding ip.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Synproxy only appears to work on the interface with the default gateway
(egress). I could never make it work on a firewall with more than 1
external interface properly.
I don't know if this is a bug or by design.
Tom
Well, only one interface is set to be a default gateway out, the
other has an IP with no gateway, but a manual route entry for how to
reach the client machine. I've also tried applying the synproxy rules on
the interface facing the client heading outbound to no avail.
On 7/28/2010 5:26 AM,
| pf | em1 - switch - client
\--/
So the clients default gateway out is the switch, which doesn't send
all traffic back over the PF machine. From what you've described, the
PF synproxy box would literally have to be inline and the default gateway
On 7/29/10, Justin jus...@sk1llz.net wrote:
I got a reply on the FreeBSD lists suggesting the firewall itself -had- to
be the default gateway for the client;
Ahh. That explains it then. I was operating under the assumption that the
machine doing the synproxy would forge the reply such
This removes any chance of scalability or the ability to separate
out single targeted IP addresses. I suppose the synproxy machine would
have to in some way act as NAT - translating between the two - or
alternately, act as a NAT to establish an initial session, then insert a
state to pass
gateway out is the switch, which doesn't send
all traffic back over the PF machine. From what you've described, the
PF synproxy box would literally have to be inline and the default
gateway.
internet - em0 | pf | em1 - client
Is this the case?
On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote:
Confirmed - synproxy works great if the synproxy machine is the
default gateway for the end host.
Yes, PF has to handle every packet of a synproxy'd connection.
Sadly this means scalability (adding multiple synproxy boxes) is not
I've been playing around with PF and synproxy - tested out OpenBSD
4.1 - 4.8, and also tried FreeBSDs port. Alas, it seems that synproxy
doesn't work at all how it's described in the man pages?
internet - switch - em0 | pf rules | em1 - switch - out to client
machines.
As CARP interface are virtual interfaces oppose to physical one, does
this mean that it is consider to be may be a bridge type of operations?
So, as the man page explain synproxy doesn't work on bridge setup would
mean the below is normal?
I am curious and would like to understand why a
31 matches
Mail list logo
