Mogamat Abrahams wrote:
Joe <fbsd8@...> writes:
Your 67.205.xx.xx ip address looks like a dynamic ip address that you
use dhcp to automatically obtain all the network configuration
information needed by your host. Static ip addresses don't work that
way. You have to manually configure the static network. If I remember
correctly, for a block of 3 assignable ip addresses you need a block of
5 from your provider. The first and last ip address are used to config
the network.
This address was provided and I manually configured the nic.
You never said if you have a firewall on your host. The firewall rules
maybe dropping unsolicited inbound traffic for those 174 prefixed ip
addresses. Try putting a pass all log from that NIC rule or just a log
all rule or turn off the firewall all together and see what happens.
Verify your NAT is not trying to NAT unsolicited inbound traffic for
those 174 prefixed ip addresses.
I had no firewall installed on the machine as we were still setting up and
usually only add firewalling last. Here is something interesting though,
since compiling a custom kernel and
including:
device<><------>pf
device<><------>pflog
nooptions<----->sctp
options><------>VIMAGE
device ><------>epair
device ><------>if_bridge
options><------>NULLFS
#firewall
options MROUTING # Multicast routing
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #enable logging to syslogd(8)
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default
options IPFIREWALL_FORWARD #packet destination changes
options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_DNS
options ACCEPT_FILTER_HTTP
options ZERO_COPY_SOCKETS
My JAILS now both receive and respond to traffic! This was the only change i
remember making.
Just running on firewall_type="OPEN" and have not even defined any other
rules.
So the problem seems solved, however still not sure what fixed it....!! Is
NAT a requirement
for Jail networking where the default gateway is not on the same subnet as
the Jail?
Mogamat Abrahams
It's customary to post your solution as the last post in this thread.
Since you have so many kernel options included it would be nice to know
which one really made the difference.
BY process of limitation
nooptions sctp problem was fixed in 8.1-release
device pf your not using this firewall
device pflog
options ACCEPT_FILTER_DATA These 4 have never been talked about
options ACCEPT_FILTER_DNS before in vnet context. Not likely
options ACCEPT_FILTER_HTTP to have any bearing on your problem.
options ZERO_COPY_SOCKETS
Since your problem was happening with both if_bridge/epair and netgraph
vnet networks seems unlikely that
device epair
device if_bridge
compiled into the kernel has any bearing on your problem.
My money is on
options MROUTING # Multicast routing
May I suggest you remove the above kernel options and recompile with
modules. If it works then you know what kernel option is the solution to
a vnet jail receiving inbound traffic. Then post the if_bridge/epair
commands you used to create your vnet/vimage inbound and outbound
network. Your solution post provides an answer (solution) for people
who search the list email archives who have the same problem. Doing this
is how you repay the people who help you on this list.
_______________________________________________
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
