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 (tcp
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.
https://www.openbsd.o
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 interface
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 con
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 to port = flags
> > > > S/SA synproxy state
> > > >
>
> Originally you posted pass in quick. Keep the quick in there, not for
> any reason other than I ha
> > > pass all flags S/SA
> > > pass in on pppoe0 inet proto tcp from to 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 f
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 to 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 sy
On cs, aug 16, 2012 at 17:18:08 +0200, Christopher Zimmermann wrote:
> On Thu, 16 Aug 2012 14:37:50 +0200
> LEVAI Daniel 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 appreciat
On Thu, 16 Aug 2012 14:37:50 +0200
LEVAI Daniel 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
> # pfctl -sr
> pass all flags S/SA
> pass in on pppoe0 inet proto tcp from to 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 t
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
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,
> 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.
--
___
'Wr
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:
FPU
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 in
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 650
Hi
try : pass in on $ext_if proto tcp to $ext_ip port imap synproxy state
@plus
2012/7/24 LEVAI Daniel
> 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
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 \
(sou
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
* Justin [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
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 t
On 7/29/10, Ryan McBride 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 separate 3-way h
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
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.
internet - em0 | pf | em1 -> client
Is this the case?
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 al
On 7/29/10, Justin 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 that the TARGET
t; em0 | 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 a
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,
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
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 simpl
31 matches
Mail list logo
