On 06/26/2014 04:09 AM, Tuyosi Takesima wrote:
hi,all.
I tried in various ways, but I can not do 'nat-to private address'.
I think that nat-to global address is OK but nat-to private address is
NO .
Is there another way (for example rdr, rdr-to) ?
I myself can't do .
sorry for poor
thanks for your advise
I write down more detail .
IN case of Debian , regardless security
internet
|
router
192:168.0.1
|
192.168.0.x
debian firewall :udhcpdiptables
192.168.11.1
|iptables -t nat -P PREROUTING ACCEPT
|
On Thu, Jun 26, 2014 at 07:00:22PM +0900, Tuyosi Takesima wrote:
thanks for your advise
I write down more detail .
IN case of Debian , regardless security
internet
|
router
192:168.0.1
|
192.168.0.x
debian firewall :udhcpdiptables
192.168.11.1
|
I pick
--
# match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
---
from http://www.openbsd.org/faq/pf/example1.html
But, this match rules don't work .
accordin to man pf.conf
10.0.0.0 - 10.255.255.255 (all
Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!
On Thu, Jun 26, 2014 at 07:34:05PM +0900, Tuyosi Takesima wrote:
I pick
--
# match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
---
from http://www.openbsd.org/faq/pf/example1.html
But, this match
On Thu, Jun 26, 2014 at 07:34:05PM +0900, Tuyosi Takesima wrote:
I pick
--
# match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
---
from http://www.openbsd.org/faq/pf/example1.html
But, this match
On 2014-06-26, Tuyosi Takesima nakajin.fu...@gmail.com wrote:
I pick
--
# match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
---
from http://www.openbsd.org/faq/pf/example1.html
But, this match rules
On Thu, Jun 26, 2014 at 12:14:42PM +0300, Gregory Edigarov wrote:
On 06/26/2014 04:09 AM, Tuyosi Takesima wrote:
I tried in various ways, but I can not do 'nat-to private address'.
I think that nat-to global address is OK but nat-to private address is
NO .
Did you enable IP
Hello Tuyosi,
Thursday, June 26, 2014, 5:34:05 AM, you wrote:
TT accordin to man pf.conf
TT 10.0.0.0 - 10.255.255.255 (all of net 10, i.e. 10/8)
TT 172.16.0.0 - 172.31.255.255 (i.e. 172.16/12)
TT 192.168.0.0 - 192.168.255.255 (i.e. 192.168/16)
TT nat-to is usually applied outbound. If applied
Hi,
I noticed that since I upgraded to 5.5, the two keys that controls the
screen brightness do not work anymore, my LCD is constantly set to a
mid-dark. This happens when the new framebuffer console runs, but also
when X11 runs.
During BIOS post or furing the first boot phase, setting
Fri, Jun 27, 2014 at 00:18:57 +0200, Riccardo Mottola may have written:
Hi,
I noticed that since I upgraded to 5.5, the two keys that controls the
screen brightness do not work anymore, my LCD is constantly set to a
mid-dark. This happens when the new framebuffer console runs, but also when
I have this exact same kernel panic. Unfortunately, it's occurring on a
host at a remote co-lo. Does anyone know a way that I can get the
on-site tech to suppress the assertion by way of some boot-time
configuration? Then at least I can get this machine up and running so I
can immediately
Having done a little man page reading on boot-time configuration, I
learned about the existence of ukc. I'm wondering whether something like
ukc disable acpi0
might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is
Scott Vanderbilt [li...@datagenic.com] wrote:
Having done a little man page reading on boot-time configuration, I learned
about the existence of ukc. I'm wondering whether something like
ukc disable acpi0
That or disable acpi
might circumvent the kernel panic and allow the boot to
I just updated from a June 17 to June 26 snapshot. The ssh-add utility
now fails immediately:
$ ssh-add
Cannot parse /home/josh/.ssh/id_rsa: invalid format
If I restore the /usr/bin/ssh-add program from the June 17 snap, it works
fine.
Between these two snapshots there was a major bump for
16 matches
Mail list logo
