Re: ipfw - accessing DMZ from LAN
W dniu 2011-09-30 17:44, Freddie Cash pisze: that's the correct behaviour, as the public IPs are physically assigned to the interfaces on the router. Thus, connecting to the public IPs from the router ... will connect to the router. You need to ping the private IPs from the router, since the router is directly connected to the private networks. And how about pinging from other DMZ host to DMZ host (both are in the same subnet) ? Am I able to allow them to contact using public IPs? Regards, -- Marek Salwerowicz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
On Oct 1, 2011 12:16 PM, "Marek Salwerowicz" wrote: > > W dniu 2011-09-30 17:44, Freddie Cash pisze: > >> >> that's the correct behaviour, as the public IPs are physically assigned to >> the interfaces on the router. Thus, connecting to the public IPs from the >> router ... will connect to the router. >> >> You need to ping the private IPs from the router, since the router is >> directly connected to the private networks. >> > And how about pinging from other DMZ host to DMZ host (both are in the same subnet) ? > Am I able to allow them to contact using public IPs? No. They would have to connect using private IPs. However, you could setup split-DNS or views and just configure everything to connect using hostnames. It's extra work to setup, but does make things easier down-the-road. Freddie fjwc...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 multicast listener discovery
"Rainer Bredehorn" wrote in <20110930074856.282...@gmx.net>: Br> Br> > Could you show us more specifics about your configuration and packet Br> > dump in question? Br> Br> Yes! It's the FreeBSD 8.2 release. The only thing which is activated in the rc.conf is ipv6. Br> I've included the ifconfig output and a wireshark capture. Br> The capture is taken during the startup of the FreeBSD system. Br> I would like to know where the address ff02::2:2d75:f2b8 comes from. Thank you. I could not reproduce this on several 8.2 boxes around me yet, but do you have a ping response from ff02::2:2d75:f2b8%rl0? -- Hiroki pgpyPW4QAQIYS.pgp Description: PGP signature
Re: Intel NIC stops working
Hi, I see that you use MTU 9000, have you tried to increase kern.ipc.nmbjumbo9? Can you also show output of `vmstat -z | grep mbuf'? -- Andrey Zonov 16.08.2011 0:10, Johannes пишет: Hi, I use an Intel dual nic for my home server. About two weeks ago, it started to randomly stop working. A reboot solved this problem. Today it did not even work after a reboot. Since the cooling of my server was insufficient for this summers heat, it might be a hardware issue. I already checked the cable, that seems to be fine. I also ran the Intel diagnostics (on windows) on the cable and on the card, which showed that everything is ok. Any idea what the reason might be is appreciated :) See debug infos below. What is especially strange is dev.em.1.debug: -1. I cannot change this, it will stay at -1. Also, the error count numbers from sysctl are mostly the same, which is very strange. uname -a FreeBSD frege.fritz.box 8.2-STABLE FreeBSD 8.2-STABLE #15: Tue Aug 9 00:00:57 CEST 2011 r...@frege.fritz.box:/usr/obj/usr/src/sys/FREGE amd64 netstat -i NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll em19000 00:15:17:51:b4:8f 69 45908905416340 0 61 13116830118930 6558415059465 pciconf -lv em0@pci0:1:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet em1@pci0:1:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet sysctl dev.em.1 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x125e class=0x02 dev.em.1.%parent: pci1 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.eee_control: 0 dev.em.1.link_irq: 0 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 4294967295 dev.em.1.rx_control: 4294967295 dev.em.1.fc_high_water: 55296 dev.em.1.fc_low_water: 53796 dev.em.1.queue0.txd_head: 4294967295 dev.em.1.queue0.txd_tail: 4294967295 dev.em.1.queue0.tx_irq: 0 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 4294967295 dev.em.1.queue0.rxd_tail: 4294967295 dev.em.1.queue0.rx_irq: 0 dev.em.1.mac_stats.excess_coll: 4947802323840 dev.em.1.mac_stats.single_coll: 4947802323840 dev.em.1.mac_stats.multiple_coll: 4947802323840 dev.em.1.mac_stats.late_coll: 4947802323840 dev.em.1.mac_stats.collision_count: 4947802323840 dev.em.1.mac_stats.symbol_errors: 4947802323840 dev.em.1.mac_stats.sequence_errors: 4947802323840 dev.em.1.mac_stats.defer_count: 4947802323840 dev.em.1.mac_stats.missed_packets: 4947802323925 dev.em.1.mac_stats.recv_no_buff: 4947802323840 dev.em.1.mac_stats.recv_undersize: 4947802323840 dev.em.1.mac_stats.recv_fragmented: 4947802323840 dev.em.1.mac_stats.recv_oversize: 4947802323840 dev.em.1.mac_stats.recv_jabber: 4947802323840 dev.em.1.mac_stats.recv_errs: 4947802323840 dev.em.1.mac_stats.crc_errs: 4947802323840 dev.em.1.mac_stats.alignment_errs: 4947802323840 dev.em.1.mac_stats.coll_ext_errs: 4947802323840 dev.em.1.mac_stats.xon_recvd: 4947802323840 dev.em.1.mac_stats.xon_txd: 4947802323840 dev.em.1.mac_stats.xoff_recvd: -1152 dev.em.1.mac_stats.xoff_txd: 4947802323840 dev.em.1.mac_stats.total_pkts_recvd: 4947802324218 dev.em.1.mac_stats.good_pkts_recvd: 4947802324133 dev.em.1.mac_stats.bcast_pkts_recvd: 4947802323919 dev.em.1.mac_stats.mcast_pkts_recvd: 4947802324054 dev.em.1.mac_stats.rx_frames_64: 4947802323840 dev.em.1.mac_stats.rx_frames_65_127: 4947802323985 dev.em.1.mac_stats.rx_frames_128_255: 4947802323879 dev.em.1.mac_stats.rx_frames_256_511: 4947802323949 dev.em.1.mac_stats.rx_frames_512_1023: 4947802323840 dev.em.1.mac_stats.rx_frames_1024_1522: 4947802323840 dev.em.1.mac_stats.good_octets_recvd: 60519 dev.em.1.mac_stats.good_octets_txd: 4643 dev.em.1.mac_stats.total_pkts_txd: 4947802323860 dev.em.1.mac_stats.good_pkts_txd: 4947802323860 dev.em.1.mac_stats.bcast_pkts_txd: 4947802323840 dev.em.1.mac_stats.mcast_pkts_txd: 4947802323860 dev.em.1.mac_stats.tx_frames_64: 4947802323840 dev.em.1.mac_stats.tx_frames_65_127: 4947802323848 dev.em.1.mac_stats.tx_frames_128_255: 4947802323846 dev.em.1.mac_stats.tx_frames_256_511: 4947802323843 dev.em.1.mac_stats.tx_frames_512_1023: 4947802323843 dev.em.1.mac_stats.tx_frames_1024_1522: 4947802323840 dev.em.1.mac_stats.tso_txd: 4947802323840 dev.em.1.mac_stats.tso_ctx_fail: 4952097291135 dev.em.1.interrupts.asser
Re: strange ping on local address
Hi, Yes, that helps. Source IP address is now the same as destination. Also helps reconfigure main interface, and now source IP address is 127.0.0.1 (and that's correct behaviour). -- Andrey Zonov 30.07.2011 23:43, Brian Somers пишет: On Fri, Jul 22, 2011 at 02:54:11PM +0700, Rashid N. Achilov wrote: When I try to ping local interface - ping missed! When I try to ping this interface with -S key (specified the same address) - working. What's a bug? In RELENG_7 worked. local interface on box: em0: flags=8943 metric 0 mtu 1500 options=219b ether 00:xx:xx:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX) status: active ping ordinary: master:[root] 105>ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss ping with -S key: master:[root] 106>ping -S 192.168.1.1 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.022 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.022/0.026/0.030/0.004 ms master:[root] 103>uname -a FreeBSD master.askd.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 15 18:23:18 NOVST 2011 r...@master-new.askd.gmbh:/usr/obj/usr/src/sys/Master i386 What's a terrible? I'm understand, that ping "itself" is rarely situation, but it worked in 7.x! What happens if you "route delete 192.168.1.1" and then try the ping without using -S? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
