Running openbsd 6.9 stable here
I am not able to use a pf rule using route-to/reply-to with an ipv6
linklocal address.
example:
pass out inet6 route-to fe80::abcd%em0
The syntax is valid and therefore is accepted but the "%em0" is striped
out when config is pushed.
The packe
Hello,
Managed to figure it out.
Apparently one also need to specify the default gateway of the
interface in question (vlan10 in this case).
So this set works:
table { 4.3.2.1 }
pass in quick on vlan10 proto icmp reply-to (vlan10 )
Anyone has any idea why? From the generated rule it is
Hello,
I am trying out the reply-to option in pf to force icmp echo replies
back on the same interface (vlan10) where they came in.
The problem I am seeing is that the destination mac address of the
replies are set to ethernet next-hop of the default route (vlan11).
Am I using this correctly
Apologies, correction:
obsd3# pfctl -f /etc/pf.conf
Should be:
obsd2# pfctl -f /etc/pf.conf
Joe
On Sat, May 12, 2018 at 9:37 PM Joseph Crivello
wrote:
> I cannot get reply-to working with if-bound under any circumstances. It
> works fine with floating, though.
> Is this expected
I cannot get reply-to working with if-bound under any circumstances. It
works fine with floating, though.
Is this expected behavior? The (similar) route-to option works fine with
if-bound rules, and I cannot find any documentation that states reply-to
cannot be used with if-bound rules.
Assuming
routing
table entries that forward to router #2 on gif0.
My objective is to configure an additional pass rule that would allow SSH
traffic destined for router #1 to pass in and out on trunk0.
The problem is that the aforementioned routes on gif0 cause packets sent in
reply to incoming SSH traffic to
would be usefull, route-to (tun0:peer)@tun0 feels 'legit'
1 pass in quick on vether2 from (vether2:network) to 10/8 rdr-to 10.1.2.3
2 pass in quick on vether2 from (vether2:network) to 10/8 rdr-to 10.1.2.3
reply-to 172.16.1.8@em5
3 pass in quick on vether2 from (vether2:network) to 1
y are the only solution, but it seems to be the easiest
one to deploy, in your case.
> if block rules with return do create a state, why do they not respect
> the reply-to ?
Now you got me. I would need to read the source to answer you, but I
believe that reply-to ends up only working f
t a packet leaving a interface but it
should be on the other, you force route-to rules (not reply-to) on them.
Block rules with return do create states, but as soon as the packet is
sent, they enter in TIME_WAIT status (as it should be). Do you really,
really, need to return the packets? Perhaps in you
be on the other, you force route-to rules (not reply-to) on them.
Block rules with return do create states, but as soon as the packet is
sent, they enter in TIME_WAIT status (as it should be). Do you really,
really, need to return the packets? Perhaps in your case you can benefit
from routing
on $vlan10_if from reply-to
($vlan10_if $vlan10_gw)
@50: block return in quick log on $vlan20_if from reply-to
($vlan20_if $vlan20_gw)
Default gw is on vlan10 interface.
When I try to connect on second interface (vlan20) the returns are
coming from first interface
(vlan10).
pflog:
Aug 03 11
) flags
S/SA keep state (no-sync) reply-to 10.1.101.1@vlan101
pass out log quick inet from any to 192.168.1.1 flags S/SA
The actual rule is:
pass in quick log on $mgmt_if from $admin to ($mgmt_if) keep state
(no-sync) reply-to ($mgmt_if $mgmt_gw)
On pf log I get
Apr 01 18:24:03.077339 rule 0/(match
Hi,
I had the following rule in pf which served me well so far. After
updating today to current (from 5.4 Jan)
icmp replied from firewall stopped working.
# pfctl -sr | head -2
pass in log quick on vlan101 inet from 192.168.1.1 to (vlan101) flags
S/SA keep state (no-sync) reply-to
will it honor the reply-to filter option.
To get that to work however, an interface that is a reply-to target must
be processed by pf, and in my case, both interfaces which I have used as
targets for default routes (vio0 and vio1) were skipped by pf (set skip
on vio*).
To figure this out it was
Hi All,
I have a question regarding ‘reply-to’ with pf.conf and its expected
behavior. I have tested this on 5.2, 5.3, 5.4 and latest snapshot from
20140228. It could well be that I am doing something wrong but after
reading pf.conf manpage, FAQs on openbsd.org and searching the mailing
lists I
Hello,
Does pfsync currently support failover of a pf established
'reply-to'/'route-to' states when Carp failover happens?
I`ve noticed that states created with pf rules that contains
'reply-to'/'route-to', after switching to backup server are using defau
Fellow users,
do I understand correctly that RST replies to packets blocked with pf
cannot be arbitrarily routed?
pf.conf(5) says that "(...) reply-to is useful only in rules that create
state". Since 'block' and 'match' rules seem to (understandably) not cre
Hi,
I had this pf rules
int_if = "trunk1"
cosmo = 172.16.99.249
pass in on $int_if from to ! route-to $cosmo@$int_if
However, when I issue a pfctl -sr, I get
pass in on trunk1 inet from to ! flags S/SA route-to
172.16.99.249@$int_if
Shouldn't this @$int_if be translated to trunk1 ?
Is th
Hi Patrick,
Thanks for your response. I've also been using this legacy format, but when
I tried the new format, pfctl didn't complain, but didn't apply it.
sperreault@ confirmed this is a known issue, and will be addressed in time.
Thanks for you attention.
On Thu, Nov 1, 2012 at 4:33 PM, Pat
Le Thu, 1 Nov 2012 13:28:18 -0200,
Fernando Braga a écrit :
Hello,
> pass in on $int_if from to ! route-to
> $cosmo@$int_if
>
> However, when I issue a pfctl -sr, I get
>
> pass in on trunk1 inet from to ! flags S/SA
> route-to 172.16.99.249@$int_if
>
> Shouldn't this @$int_if be translat
the syntax should be like this:
pass in on $int_if from to ! route-to ($int_if $cosmo)
On Thu, Nov 1, 2012 at 1:28 PM, Fernando Braga wrote:
> Hi,
>
> I had this pf rules
>
> int_if = "trunk1"
> cosmo = 172.16.99.249
>
> pass in on $int_if from to ! route-to $cosmo@$int_if
>
> However, when I
Hi,
I had this pf rules
int_if = "trunk1"
cosmo = 172.16.99.249
pass in on $int_if from to ! route-to $cosmo@$int_if
However, when I issue a pfctl -sr, I get
pass in on trunk1 inet from to ! flags S/SA route-to
172.16.99.249@$int_if
Shouldn't this @$int_if be translated to trunk1 ?
Is th
--
> ext_if0 = "tun0"
> ext_if1 = "tun1"
> ext_if2 = "tun2"
> int_fw = # my internal firewall's address
> ...
>
> pass in quick on $ext_if0 proto udp from any to any port 1194 \
> rdr-to $int_fw port 1
from any to any port 1194 \
rdr-to $int_fw port 1194 reply-to ( $ext_if0 $ext_if0:peer )
pass in quick on $ext_if1 proto udp from any to any port 1194 \
rdr-to $int_fw port 1194 reply-to ( $ext_if1 $ext_if1:peer )
pass in quick on $ext_if2 proto udp from any to any port 1194 \
rdr-to $i
ass in quick log on $vpn
pass out quick log on $vpn
pass in log on $wan_if inet proto udp from any to $wan_if \
port 1194 reply-to ($wan_if $wan_gw)
I need your advice to solve this issue?
Anyway, if i set to with TCP like this
pass in log on $wan_if inet proto tcp from any to $wan_if \
t could
> be done using "reply-to" pf keyword.
> however, I'm not sure "reply-to" is runnung well with carp. Can anyone
> proof such thing ?
>
> I did
>
> set skip on lo
>
> pass in to X.X.X.X reply-to (carp5 X.X.X.N)
> pass in to Y.Y.
hello!
I'm running multihomed server (two servers in carp cluster).
say carp5 is default route and carp2 is another ISP. I want to see
outgoing packets in the interface they came in. I supposed, it could
be done using "reply-to" pf keyword.
however, I'm not sure "reply
Hi all,
I want to set-up a service redirector with relayd and the reply-to
feature of pf.conf, but I meet a problem: The reply-to pf rule is
matched, but there is no modification of the return traffic (the
firewall send the reply to the default gateway and not to the gateway
forced in the reply-to
On Mon, Mar 22, 2010 at 06:05:37PM +0100, Didier Wiroth wrote:
> Hello,
> (I'm using current with smtpd.)
> I'm sending mail reports to a mail address which is defined in the
> alias file like this:
> didier: dwir...@company.com
>
> My smtpd.conf is:
> listen on lo0
> map "aliases" { source db "/e
Hello,
(I'm using current with smtpd.)
I'm sending mail reports to a mail address which is defined in the
alias file like this:
didier: dwir...@company.com
My smtpd.conf is:
listen on lo0
map "aliases" { source db "/etc/mail/aliases.db" }
accept for local deliver to mbox
accept for all relay via m
Found a fix for it...
reply-to ($www_if ($www_if))
Got to put brackets around $www_if now.
"pppoe0"
www_if = "pppoe1"
set skip on {lo rl0}
match out on $nat_if inet from nat-to ($nat_if:0)
pass# to establish keep-state
pass in log on $www_if \
inet proto {tcp udp} \
reply-to ($www_if $www_if)
# By default, do not permit remote connections
Check that another pass rule later in the file is not overriding it.
Maybe try with quick.
I have 2 pppoe connections pppoe0 and pppoe1.
pppoe0 is my default gateway and people can access my http server via
its IP address.
But it is not working for pppoe1's IP address.
I tried the following pf rule for pppoe1:
pass in log on pppoe1 \
inet proto {tcp udp} \
rep
In case people reading this thread didn't notice the commits yet,
this works again in -current (thanks jsg and claudio). Make sure you
upgrade pfctl and kernel together.
Hello, Stuart.
On 8 October 2009 G. 15:03:13 Stuart Henderson wrote:
> On 2009-09-25, Vadim Zhukov wrote:
> > 2. Is it OK if I'll hack it to make possible even crazy rule like
> > this:
> >
> > pass in on $if1 from $a to $b rdr-to $c \
> > ro
On 2009-09-25, Vadim Zhukov wrote:
> 2. Is it OK if I'll hack it to make possible even crazy rule like this:
>
> pass in on $if1 from $a to $b rdr-to $c \
> route-to ($if3 $gt3) reply-to ($if2 $gt2) dup-to $if4
>
> ... or it's not intended to be so, or it&
On 25 September 2009 11:49:48 Henning Brauer wrote:
> On 25 September 2009 08:34:03 Vadim Zhukov wrote:
> > So as far as I can understand, pf_rule.rdr pool is used for
> > route-to/reply-to/dup-to options. Now I have a few stupid questions:
> >
> > 1. Is it intended to
* Vadim Zhukov [2009-09-25 06:36]:
> Hello all, especially network hackers (you write cool code, BTW, thanks!)
>
> (Sending this email to another list as now it's more technical. I hope)
>
> Stupid me finally found the reasons for such route-to/reply-to behavior:
>
Hello all, especially network hackers (you write cool code, BTW, thanks!)
(Sending this email to another list as now it's more technical. I hope)
Stupid me finally found the reasons for such route-to/reply-to behavior:
/usr/src/sbin/pfctl/parse.y (introduced in 1.563 and modified
Hi,
Am 11.09.2009 00:58, schrieb Laurent Ghigonis:
> On Fri, 11 Sep 2009 02:23:54 +0400
> Vadim Zhukov wrote:
>> Hello all.
>>
>> Can anyone ack that route-to/reply-to rules do not work on amd64?
>> I have the following rule in pf.conf:
>>
>> pass in qu
On Fri, 11 Sep 2009 02:23:54 +0400
Vadim Zhukov wrote:
> Hello all.
>
> Can anyone ack that route-to/reply-to rules do not work on amd64?
> I have the following rule in pf.conf:
>
> pass in quick on $limit_if inet proto icmp icmp-type echoreq \
> reply-to ($limit_
Hello all.
Can anyone ack that route-to/reply-to rules do not work on amd64?
I have the following rule in pf.conf:
pass in quick on $limit_if inet proto icmp icmp-type echoreq \
reply-to ($limit_if $limit_gw)
It does not work (IPs replaced via corresponding macros by me),
see tcpdump(8
Hi Henning and Misc@,
On Sun, 06 Sep 2009 21:21:15 +0700, Henning Brauer
wrote:
* Insan Praja SW [2009-09-06 16:10]:
Hi Misc@,
I can't seem to use this syntax any more:
pass in quick log on vlan101 reply-to {(vlan101 a.b.c.14)} inet proto
icmp from to vlan101:0 keep state (s
* Insan Praja SW [2009-09-06 16:10]:
> Hi Misc@,
> I can't seem to use this syntax any more:
>
> pass in quick log on vlan101 reply-to {(vlan101 a.b.c.14)} inet proto
> icmp from to vlan101:0 keep state (sloppy source-track
> global) flags any tag INTERNAL_IN
&g
Hi Misc@,
I can't seem to use this syntax any more:
pass in quick log on vlan101 reply-to {(vlan101 a.b.c.14)} inet proto icmp
from to vlan101:0 keep state (sloppy source-track global)
flags any tag INTERNAL_IN
while this is working:
pass in quick log on vlan101 reply-to {(vlan101
s form
rdr pass on $ext_if proto tcp from xxx to port 443 -> 192.168.0.1 port 443
nat on $int_if from any to 192.168.0.1 -> ($int_if:0)
how to create a rule with reply-to or route-to ?
I Sniffed traffic on comp2 and the requisition is the external ip
Exists one form without nat on int_if
rt 443 -> 192.168.0.1 port 443
nat on $int_if from any to 192.168.0.1 -> ($int_if:0)
how to create a rule with reply-to ?
Thanks in advanced
Le 09/08/2009 20:55, Samuel Baldwin a C)crit :
Would it be possible for this to be set when the list delivers mail?
Most other mailing lists do and it's a bit of a lifesaver for those
who are used to hitting "reply" to reply to the list.
Doesn't your mail client fea
Samuel Baldwin wrote:
> Would it be possible for this to be set when the list delivers mail?
> Most other mailing lists do and it's a bit of a lifesaver for those
> who are used to hitting "reply" to reply to the list.
>
life saver?
You think it safer to reply to the l
ppoe0 inet proto tcp from any to (pppoe0) port 25 -> 192.168.0.50
rdr on pppoe1 inet proto tcp from any to (pppoe1) port 25 -> 192.168.0.50
pass in on pppoe0 reply-to { pppoe0 0.0.0.1 ) proto tcp to
192.168.0.50 port 25 flags S/SA synproxy state
pass in on pppoe1 reply-to { pppoe1 0.0.0.
Would it be possible for this to be set when the list delivers mail?
Most other mailing lists do and it's a bit of a lifesaver for those
who are used to hitting "reply" to reply to the list.
--
Samuel Baldwin - logik.li
I find it somewhat astonishing, bordering on the incredible, that
someone who claims to be knowledgeable about such things as spamd and
a few related pieces of software would first post to this list with a
reply-to address that the recipient mail server bounces as
undeliverable, then later
On Thu, 8 Nov 2007 20:40:00 -0500, Steven Surdock wrote:
>> I assume you are running OpenVPN in UDP mode? ...
>
>Yes. But I also run a second OpenVPN process in TCP mode (port 443) to
>get around a few (very few) places that still only allow 80/443. UDP
>has less overhead and "feels" faster, but
Nick Golder wrote:
> On 2007-11-07 14:29 -0500, Steven Surdock wrote:
>> Nick Golder wrote stuff:
...
> Is this a PF bug?
[Shrug]. They way it _seemed_ to work (for me, when I implemented the
system back on 3.8 or 3.9, YMMV) was that "route-to/reply-to" caused the
packet
On 2007-11-07 14:29 -0500, Steven Surdock wrote:
> Nick Golder wrote:
> > I am trying to serve out OpenVPN (port 1194 UDP) through
> > multiple external
>
> I solved this problem by running OpenVPN on the loopback only and using
> "rdr" and "
> pass in o
Nick Golder wrote:
> I am trying to serve out OpenVPN (port 1194 UDP) through
> multiple external
I solved this problem by running OpenVPN on the loopback only and using
"rdr" and "
pass in on $if reply-to...) on the incoming traffic.
-Steve S.
I am trying to serve out OpenVPN (port 1194 UDP) through multiple external
interfaces. It works fine for the external interface $ext_if1 which has
a default route. When I try to serve port 1194 out on $ext_if2 using
'reply-to', tcpdump shows the packets arrive in on $ext_if2 but
the r
Hi,
Thank you for correcting me.
I did as you noted, placed those lines in openbsd-submit.mc (at the bottom).
Here's the 'make' step, from /usr/share/sendmail/cf/, it had an error:
$ sudo make openbsd-submit.cf
rm -f openbsd-submit.cf
( cd /usr/share/sendmail/cf && /usr/bin/m4
/usr/share/sendma
> I went ahead and made a backup of /etc/mail/submit.cf and copied it into
> (replacing) /etc/mail/submit.cf.
>
> Correction: I copied the newly created openbsd-submit.cf into/replacing
> /etc/mail/submit.cf.
Hi Sean,
> I realize this isn't directly OpenBSD-related, though believe I came
> across a message in misc a while back
That was me (on ports@, not misc@).
> that discussed including a reply-to field in mutt.
Er, well, mutt is able to set the Reply-To: all right.
It is trivial to
On 2007/11/03 05:59, Sean Darby wrote:
> 1. cd /etc/mail/
You are confused between /etc/mail (dir holding config files
used by sendmail) and /usr/share/sendmail/cf (dir holding files
used to *build* these config files).
cd /usr/share/sendmail/cf
copy submit.mc to openbsd-submit.mc and add these l
Thank you! :^)
So would I do this:
1. cd /etc/mail/
2. cp submit.cf openbsd-submit.cf
3. ...add this to openbsd-submit.cf:
define(`confCT_FILE', `-o MAIL_SETTINGS_DIR`'trusted-users')dnl
FEATURE(`use_ct_file')dnl
4. make openbsd-submit.cf (while in /etc/mail/)
5. cp openbsd-submit.cf sendmail.c
On Sat, 3 Nov 2007, Stuart Henderson wrote:
type 'make openbsd-submit.cf' and copy the resulting file to
/etc/mail/sendmail.cf
Shouldn't it be /etc/mail/submit.cf
--
Antoine
On 2007/11/03 11:01, Antoine Jacoutot wrote:
> On Sat, 3 Nov 2007, Stuart Henderson wrote:
>> type 'make openbsd-submit.cf' and copy the resulting file to
>> /etc/mail/sendmail.cf
>
> Shouldn't it be /etc/mail/submit.cf
Yes, oops!
On 2007/11/02 18:48, Sean Darby wrote:
> Thank you very much for the info! I appreciate it a lot.
>
> I've now updated my /etc/mail/trusted-users file with my "[EMAIL PROTECTED]"
> address (which is what I currently have in my "from:" field in my muttrc).
>
> Regarding the link you provided (on c
On Fri 2007.11.02 at 18:53 -0500, Sean Darby wrote:
> I'm still running OpenBSD 4.1, my mutt is at 1.4.2.2i (2006-07-14).
>
> Is there a way to get mutt 1.5.15+ while still on 4.1?
well, not officially...it is in 4.2 however :)
> What can I find out about that
> smtp_url variable? (How to use it
> er, no.
>
> /usr/share/sendmail/README:
> names of users that will be ``trusted'', that is, able to
> set their envelope from address using -f without generating
> a warning message.
>
> In other words, you list your local Unix user in the file, not an email
> address.
>
> DS
>
Okay. My lo
On Nov 2, 2007 4:48 PM, Sean Darby <[EMAIL PROTECTED]> wrote:
> Hi Stuart,
>
> Thank you very much for the info! I appreciate it a lot.
>
> I've now updated my /etc/mail/trusted-users file with my "[EMAIL PROTECTED]"
> address (which is what I currently have in my "from:" field in my muttrc).
er,
Hi Okan,
Thank you for the info - very much appreciated.
I'm still running OpenBSD 4.1, my mutt is at 1.4.2.2i (2006-07-14).
Is there a way to get mutt 1.5.15+ while still on 4.1?
(Hopefully without messing with any current emails/settings or 4.1settings.)
I'm not a pro with computers but alwa
Hi Stuart,
Thank you very much for the info! I appreciate it a lot.
I've now updated my /etc/mail/trusted-users file with my "[EMAIL PROTECTED]"
address (which is what I currently have in my "from:" field in my muttrc).
Regarding the link you provided (on cvs.openbsd.org...)
How would I use tha
Hello,
I realize this isn't directly OpenBSD-related, though believe I came across a
message in misc a while back that discussed including a reply-to field in mutt.
Lately I have been having difficulty getting my mutt mail to successfully
deliver to several addresses. Google mail do
On Fri 2007.11.02 at 22:50 +, Stuart Henderson wrote:
> On 2007/11/02 17:38, Sean Darby wrote:
> > > I checked the full headers and found:
> > > X-Authentication-Warning: (myhostname): sean set
> > > sender to (alternateaddress) using -f
>
> this can be fixed with something like
> http://cvs.o
On 2007/11/02 17:38, Sean Darby wrote:
> > I checked the full headers and found:
> > X-Authentication-Warning: (myhostname): sean set
> > sender to (alternateaddress) using -f
this can be fixed with something like
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=4951
(and add yours
> Hello,
>
> I realize this isn't directly OpenBSD-related,
> though believe I came across a message in misc a
> while back that discussed including a reply-to field
> in mutt.
>
> Lately I have been having difficulty getting my mutt
> mail to successfully delive
s in on $lan proto ...
pass out on egress route-to ($wan1 $gw1) ... from $wan1:0 ...
> Ok, now I want to redirect http traffic on $wan1 to an internal server,
> is this the time to use reply-to??> Is this enough to make it work, or
> are additional rules needed?
yes, should be enoug
Hi,
I am trying to understand the differences between route-to and reply-to
in pf. Have not found any good examples in man(pf.conf) or Google.
2 wan connections, I want the traffic from the internal lan ($lan) to go
through the wan1 ($wan1) connection via NAT. Wan1 is not the default
route
On 3/17/07, Sebastian Reitenbach <[EMAIL PROTECTED]> wrote:
I use ftp-proxy on my firewall as a reverse proxy for a host on the dmz.
Please find Bill Marquette's ftp-proxy patch from pfSense CVS:
http://cvstrac.pfsense.com/dirview?d=tools/pfPorts/pftpx-routeto
I'm successfully using this in
On Sat, 17 Mar 2007, Sebastian Reitenbach wrote:
> I use ftp-proxy on my firewall as a reverse proxy for a host on the dmz. The
> incoming connections come in on one of the the external interfaces, which is
> not the default gateway of the firewall. Therefore I use reply-to statements
Hi list,
I use ftp-proxy on my firewall as a reverse proxy for a host on the dmz. The
incoming connections come in on one of the the external interfaces, which is
not the default gateway of the firewall. Therefore I use reply-to statements
on the pass in rules to make sure the answer packets are
connect to the external $cable_mail_ip, with the
second reply-to rule, where I use ($cable_if $cable_gate) then the packets
are going into the firewall, to the DMZ host. The DMZ host is answering, and
the packets arrive again on the firewall, but then they disappear. I had a
tcpdump running on all my
statement. The route-to ($cable_if
> > $cable_gate)
> > sends out my
> > packets with the MAC address of the carp device, so this works well, as I
> > expect. But when I
> > try to connect to the external $cable_mail_ip, with the second reply-to
> > rule,
&
nds out my
> packets with the MAC address of the carp device, so this works well, as I
> expect. But when I
> try to connect to the external $cable_mail_ip, with the second reply-to rule,
> where I use
> ($cable_if $cable_gate) then the packets are going into the firewall, to the
D
second reply-to rule,
where I use
($cable_if $cable_gate) then the packets are going into the firewall, to the DMZ
host. The
DMZ host is answering, and the packets arrive again on the firewall, but then
they disappear.
I had a tcpdump running on all my interfaces, but they did not showed up
84 matches
Mail list logo
