Hot answers tagged

3

The message is normal because ALTQ is not compiled into the stock FreeBSD kernel. Unless you need to use ALTQ it doesn't matter. The start up of the firewall interrupts all current connections, including your ssh session, which stops responding. Just open another terminal and log in again. The original session will eventually time out. It's a good idea to ...


2

After some more testing the pf rules, I briefly let all traffic pass and realized the mistake was that while I had pass quick on lo0 all in the pf.conf, the jail is running under lo1. I added pass quick on lo1 all and it works now. Also note that from within a jail, you should query the jail IP instead of localhost. So, in the jails resolv.conf: ...


2

The problem I see here is that you have to accept the TCP connection before you get to see the http request. So even if the system could use application level data it would not have that data at the time it needs to decide where the connection needs to go. I don't think there is much choice but to have a "reverse proxy" which terminates the TCP connection ...


2

For BSD i would look into relayd(8) - its native to OpenBSD, but i believe FreeBSD has a port too. It is quite powerful and can do more than a few things (ex., proxy, load balancer, application gateway) including what you are asking. Read through man pages, particularly the 'Filter Rules' and 'Protocols' section: ...


2

So, I am likely misunderstanding but I think you may be confusing the iptables TPROXY and REDIRECT targets - but I don't think that's important. Ignoring that, you may still be able to realize your goal. Your frustration with the rdr pf rule is because only applies to incoming packets. According to a 2005 FreeBSD-pf mailinglist post, you may be able to ...


1

127.0.0.1 is your loopback. It is always local to the machine you are on. Creating a VM means it is a new machine and it has its own internal 127.0.0.1. You could create 50 VM's and they're each going to have their own internal 127.0.0.1 and no way for the computer to know which one you want. So you should only be able to get to web pages on the VM's at ...


1

This is a script I used on El Capitan 10.11 with some success: #!/bin/bash # Reset dummynet to default config dnctl -f flush # Compose an addendum to the default config: creates a new anchor (cat /etc/pf.conf && echo 'dummynet-anchor "my_anchor"' && echo 'anchor "my_anchor"') | pfctl -q -f - # Configure the new anchor cat <<EOF ...


1

Not getting far enough to be MTU-related. You're sending a SYN, getting a SYN ACK in reply, then RSTing the connection rather than completing the TCP handshake. Something is aborting the connection. That's an unusual circumstance, nothing about that suggests a specific cause. Looks like that capture reference point is your WAN, try the same on LAN to see ...



Only top voted, non community-wiki answers of a minimum length are eligible