Hi,
I have just noticed an interaction between reply-to and synproxy.
It seems that the packets generated by the firewall as it performs
synproxying are not subject to the reply-to directive - i.e they are
routed normally.
I am not sure whether this is a bug (though I suspect so) or easily
I'm having some problems configuring PF. A firewall box with 4 NICs. Connected to one
of these I have a Postfix SMTP relay.
I've noticed that connecting to the SMTP daemon from the outside was very slow... I've
tried a manual DNS query from the SMTP relay (dig www.host.com) but it goes in
Hallo
Roberto Jobet [EMAIL PROTECTED] schrieb:
2) How can I troubleshoot this issue ?
Use tcpdump -n -e -ttt -i pflog0 to see waht you are blocking.
http://www.openbsd.org/faq/pf/logging.html
best regards maik
Maik,
I've tried this command but there's no packet filtered by the PF engine (??) and the
query goes in time out...
dig www.mercury-online.com
; DiG 2.2 www.mercury-online.com
;; res options: init recurs defnam dnsrch
;; res_send to server default -- 212.38.32.31: Connection timed out
What
Roberto Jobet wrote:
2) How can I troubleshoot this issue ?
When implementing new rulesets *always* use 'pass log' instead of 'block
log'. Watch pflog0 (using tcpdump) for a while to make sure you understand
what is being dropped and by which rule.
When you are happy, you can change the 'pass'
What rules do I need to enable ESP protocol pass through on my PF bridge.
internet/ISPExtIF (NO IP)[OpenBSD/PF Bridge]IntIF (NO
IP)-LocalLan
|
|
ManagementIF (HAS
kernel: page fault trap, code=0
Stopped at _priq_getqstats+0x5e1: cmpl $0x1, 0xc(%edx)
ddb
Sorry to e-mail you off-list, but did you find any resolution for
this
problem? I am (was) also using priq and cbq on different interfaces
successfully with 3.3-release for approx. 1