I just got Shorewall up and running on a Centos box with the aid of Webmin. I have the luxury of 64 public addresses and thus both sides of this firewall have routable addresses. No NATing! (I am a co-author of RFC 1918). This particular firewalls'' life purpose is protecting my Asterisk servers (one is also an NTP server). I **thought** I was setting up the rules right. It looks like I have a SIP registration with my VoIP provider (Broadvoice), but calling is not working. Here is what I have: cat interfaces # Pub eth0 detect VoIP eth1 detect cat zones # fw firewall Pub ipv4 # VoIP ipv4 # cat cat rules # #SECTION ESTABLISHED #SECTION RELATED SECTION NEW ACCEPT all all icmp ACCEPT all all udp 53 ACCEPT Pub VoIP tcp 80 ACCEPT Pub VoIP tcp 443 # SIP on UDP port 5060. Other SIP servers may need TCP port 5060 as well ACCEPT all- all- udp 5004:5082 ACCEPT all- all- tcp 5060 # RTP - the media stream ACCEPT all- all- udp 10000:20000 # IAX2- the IAX protocol ACCEPT all- all- udp 4569 # IAX - most have switched to IAX v2, or ought to ACCEPT all- all- udp 5036 See anything obvious here? Other than wireshark on the firewall, how might I figure out what is being blocked? All I get is a fast busy on a call. On a related note, I want a low-overhead reporting on usage and through-put on this firewall. The box is low end (per /proc/cpuinfo - bogomips : 731.66, and 256Mb memory) and I don''t want to steal cycles from the voice traffic to measure any firewall induced voice degradation. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote:> > See anything obvious here? Other than wireshark on the firewall, how > might I figure out what is being blocked? All I get is a fast busy on a > call. >I would start with the output of ''shorewall dump''. But first, read this page: http://www.shorewall.net/support.htm Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Roberto C. Sánchez wrote:> On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote: > >> See anything obvious here? Other than wireshark on the firewall, how >> might I figure out what is being blocked? All I get is a fast busy on a >> call. >> >> > I would start with the output of ''shorewall dump''.Will try.> But first, read this > page: http://www.shorewall.net/support.htmI did read it first. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Jan 01, 2008 at 01:20:37PM -0500, Robert Moskowitz wrote:> Roberto C. Sánchez wrote: > > On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote: > > > >> See anything obvious here? Other than wireshark on the firewall, how > >> might I figure out what is being blocked? All I get is a fast busy on a > >> call. > >> > >> > > I would start with the output of ''shorewall dump''. > Will try. > > But first, read this > > page: http://www.shorewall.net/support.htm > I did read it first. >Sorry. Since the flowchart indicates that for your situation you should send the output of ''shorewall dump'' to the mailing list and you did not do that, I thought you had not read the page. Anyhow, once you forward the dump output you are more likely to get something resembling competent help. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Roberto C. Sánchez wrote:> On Tue, Jan 01, 2008 at 01:20:37PM -0500, Robert Moskowitz wrote: > >> Roberto C. Sánchez wrote: >> >>> On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote: >>> >>> >>>> See anything obvious here? Other than wireshark on the firewall, how >>>> might I figure out what is being blocked? All I get is a fast busy on a >>>> call. >>>> >>>> >>>> >>> I would start with the output of ''shorewall dump''. >>> >> Will try. >> >>> But first, read this >>> page: http://www.shorewall.net/support.htm >>> >> I did read it first. >> >> > Sorry. Since the flowchart indicates that for your situation you should > send the output of ''shorewall dump'' to the mailing list and you did not > do that, I thought you had not read the page. Anyhow, once you forward > the dump output you are more likely to get something resembling > competent help.Send that hugh listing? I guess I am jsut ''trained'' not to flood a list with long dumps. Rather to be able to pull out the part(s) needed. Well here goes: SSH into the firewall, dump > to file, gFTP to move the dump here, gedit dump, cut to clipboard then paste! (simple :) ): Shorewall 4.0.7 Dump at dectop3.htt-consult.com - Tue Jan 1 13:42:55 EST 2008 Shorewall-perl 4.0.7 Counters reset Tue Jan 1 12:20:17 EST 2008 Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 1061 76589 eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 eth1_in all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 981 181K eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0 665 215K eth1_fwd all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 723 153K eth0_out all -- * eth0 0.0.0.0/0 0.0.0.0/0 0 0 eth1_out all -- * eth1 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain Drop (15 references) pkts bytes target prot opt in out source destination 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 310 40068 dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11 145 15064 dropInvalid all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:137 dpts:1024:65535 29 1404 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1900 19 1032 dropNotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 Chain Pub2VoIP (1 references) pkts bytes target prot opt in out source destination 882 169K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 1 1048 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5004:5082 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4569 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5036 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:613 98 11276 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 75 10160 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain Pub2all (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain Pub2fw (1 references) pkts bytes target prot opt in out source destination 883 50253 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:613 1 44 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 0 0 ACCEPT tcp -- * * 208.83.67.0/26 0.0.0.0/0 tcp dpts:5902:5903 0 0 ACCEPT tcp -- * * 192.168.128.0/24 0.0.0.0/0 tcp dpts:5902:5903 177 26292 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 6 1000 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain Reject (0 references) pkts bytes target prot opt in out source destination 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 0 0 dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11 0 0 dropInvalid all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:137 dpts:1024:65535 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1900 0 0 dropNotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 Chain VoIP2Pub (1 references) pkts bytes target prot opt in out source destination 630 213K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5004:5082 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4569 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5036 35 2500 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 35 2500 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain VoIP2all (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain VoIP2fw (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:613 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain all2Pub (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain all2VoIP (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain all2fw (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain dropBcast (2 references) pkts bytes target prot opt in out source destination 165 25004 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST 0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/4 Chain dropInvalid (2 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID Chain dropNotSyn (2 references) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 Chain dynamic (4 references) pkts bytes target prot opt in out source destination Chain eth0_fwd (1 references) pkts bytes target prot opt in out source destination 99 12324 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 981 181K Pub2VoIP all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain eth0_in (1 references) pkts bytes target prot opt in out source destination 178 26336 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 1061 76589 Pub2fw all -- * * 0.0.0.0/0 0.0.0.0/0 Chain eth0_out (1 references) pkts bytes target prot opt in out source destination 723 153K fw2Pub all -- * * 0.0.0.0/0 0.0.0.0/0 Chain eth1_fwd (1 references) pkts bytes target prot opt in out source destination 35 2500 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 665 215K VoIP2Pub all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain eth1_in (1 references) pkts bytes target prot opt in out source destination 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 0 0 VoIP2fw all -- * * 0.0.0.0/0 0.0.0.0/0 Chain eth1_out (1 references) pkts bytes target prot opt in out source destination 0 0 fw2VoIP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fw2Pub (1 references) pkts bytes target prot opt in out source destination 723 153K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fw2VoIP (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:613 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fw2all (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain logdrop (0 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain logreject (0 references) pkts bytes target prot opt in out source destination 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 Chain reject (7 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match src-type BROADCAST 0 0 DROP all -- * * 224.0.0.0/4 0.0.0.0/0 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-unreachable 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain shorewall (0 references) pkts bytes target prot opt in out source destination Chain smurfs (0 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match src-type BROADCAST LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:'' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match src-type BROADCAST 0 0 LOG all -- * * 224.0.0.0/4 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:'' 0 0 DROP all -- * * 224.0.0.0/4 0.0.0.0/0 Log (/var/log/messages) NAT Table Chain PREROUTING (policy ACCEPT 466 packets, 64568 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 1 packets, 1048 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Mangle Table Chain PREROUTING (policy ACCEPT 2861 packets, 497K bytes) pkts bytes target prot opt in out source destination 2861 497K tcpre all -- * * 0.0.0.0/0 0.0.0.0/0 Chain INPUT (policy ACCEPT 1061 packets, 76589 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 1646 packets, 397K bytes) pkts bytes target prot opt in out source destination 1646 397K tcfor all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 723 packets, 153K bytes) pkts bytes target prot opt in out source destination 723 153K tcout all -- * * 0.0.0.0/0 0.0.0.0/0 Chain POSTROUTING (policy ACCEPT 2236 packets, 536K bytes) pkts bytes target prot opt in out source destination 2236 536K tcpost all -- * * 0.0.0.0/0 0.0.0.0/0 Chain tcfor (1 references) pkts bytes target prot opt in out source destination Chain tcout (1 references) pkts bytes target prot opt in out source destination Chain tcpost (1 references) pkts bytes target prot opt in out source destination Chain tcpre (1 references) pkts bytes target prot opt in out source destination Conntrack Table tcp 6 430831 ESTABLISHED src=208.83.67.156 dst=208.83.67.138 sport=35294 dport=613 packets=273 bytes=17600 src=208.83.67.138 dst=208.83.67.156 sport=613 dport=35294 packets=174 bytes=20544 [ASSURED] mark=0 secmark=0 use=1 tcp 6 431997 ESTABLISHED src=208.83.67.156 dst=208.83.67.130 sport=57550 dport=613 packets=869 bytes=51280 src=208.83.67.130 dst=208.83.67.156 sport=613 dport=57550 packets=733 bytes=169416 [ASSURED] mark=0 secmark=0 use=1 udp 17 3205 src=64.34.162.221 dst=208.83.67.138 sport=5060 dport=5060 packets=4 bytes=2892 src=208.83.67.138 dst=64.34.162.221 sport=5060 dport=5060 packets=4 bytes=2298 [ASSURED] mark=0 secmark=0 use=1 udp 17 3596 src=208.83.67.138 dst=147.135.12.221 sport=5060 dport=5060 packets=467 bytes=297692 src=147.135.12.221 dst=208.83.67.138 sport=5060 dport=5060 packets=466 bytes=183763 [ASSURED] mark=0 secmark=0 use=1 udp 17 176 src=208.83.67.138 dst=208.83.67.147 sport=33069 dport=53 packets=369 bytes=23864 src=208.83.67.147 dst=208.83.67.138 sport=53 dport=33069 packets=369 bytes=52728 [ASSURED] mark=0 secmark=0 use=1 IP Configuration 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast qlen 1000 link/ether 00:e0:4c:03:33:bb brd ff:ff:ff:ff:ff:ff inet 208.83.67.130/29 brd 208.83.67.135 scope global eth0 inet6 fe80::2e0:4cff:fe03:33bb/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast qlen 1000 link/ether 00:e0:4c:03:52:57 brd ff:ff:ff:ff:ff:ff inet 208.83.67.137/29 brd 208.83.67.143 scope global eth1 inet6 fe80::2e0:4cff:fe03:5257/64 scope link valid_lft forever preferred_lft forever 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 IP Stats 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 960 16 0 0 0 0 TX: bytes packets errors dropped carrier collsns 960 16 0 0 0 0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast qlen 1000 link/ether 00:e0:4c:03:33:bb brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 761317 7733 0 0 0 0 TX: bytes packets errors dropped carrier collsns 587410 2116 252897 0 252897 0 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast qlen 1000 link/ether 00:e0:4c:03:52:57 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 440996 1694 0 0 0 0 TX: bytes packets errors dropped carrier collsns 308103 1745 0 0 0 0 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 PFKEY SPD No SPD entries. PFKEY SAD No SAD entries. /proc /proc/version = Linux version 2.6.18-53.1.4.el5 (mockbuild@builder6.centos.org) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Fri Nov 30 00:45:16 EST 2007 /proc/sys/net/ipv4/ip_forward = 1 /proc/sys/net/ipv4/icmp_echo_ignore_all = 0 /proc/sys/net/ipv4/conf/all/proxy_arp = 0 /proc/sys/net/ipv4/conf/all/arp_filter = 0 /proc/sys/net/ipv4/conf/all/arp_ignore = 0 /proc/sys/net/ipv4/conf/all/rp_filter = 1 /proc/sys/net/ipv4/conf/all/log_martians = 0 /proc/sys/net/ipv4/conf/default/proxy_arp = 0 /proc/sys/net/ipv4/conf/default/arp_filter = 0 /proc/sys/net/ipv4/conf/default/arp_ignore = 0 /proc/sys/net/ipv4/conf/default/rp_filter = 0 /proc/sys/net/ipv4/conf/default/log_martians = 0 /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0 /proc/sys/net/ipv4/conf/eth0/arp_filter = 0 /proc/sys/net/ipv4/conf/eth0/arp_ignore = 0 /proc/sys/net/ipv4/conf/eth0/rp_filter = 0 /proc/sys/net/ipv4/conf/eth0/log_martians = 0 /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0 /proc/sys/net/ipv4/conf/eth1/arp_filter = 0 /proc/sys/net/ipv4/conf/eth1/arp_ignore = 0 /proc/sys/net/ipv4/conf/eth1/rp_filter = 0 /proc/sys/net/ipv4/conf/eth1/log_martians = 0 /proc/sys/net/ipv4/conf/lo/proxy_arp = 0 /proc/sys/net/ipv4/conf/lo/arp_filter = 0 /proc/sys/net/ipv4/conf/lo/arp_ignore = 0 /proc/sys/net/ipv4/conf/lo/rp_filter = 0 /proc/sys/net/ipv4/conf/lo/log_martians = 0 Routing Rules 0: from all lookup 255 32766: from all lookup main 32767: from all lookup default Table 255: broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 208.83.67.135 dev eth0 proto kernel scope link src 208.83.67.130 broadcast 208.83.67.128 dev eth0 proto kernel scope link src 208.83.67.130 local 208.83.67.130 dev eth0 proto kernel scope host src 208.83.67.130 broadcast 208.83.67.143 dev eth1 proto kernel scope link src 208.83.67.137 broadcast 208.83.67.136 dev eth1 proto kernel scope link src 208.83.67.137 local 208.83.67.137 dev eth1 proto kernel scope host src 208.83.67.137 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table default: Table main: 208.83.67.128/29 dev eth0 proto kernel scope link src 208.83.67.130 208.83.67.136/29 dev eth1 proto kernel scope link src 208.83.67.137 169.254.0.0/16 dev eth1 scope link default via 208.83.67.129 dev eth0 ARP ? (208.83.67.131) at 00:02:A5:2B:82:EB [ether] on eth0 ? (208.83.67.138) at 00:20:35:67:93:D1 [ether] on eth1 ? (208.83.67.129) at 00:20:6F:10:15:32 [ether] on eth0 Modules ip_conntrack 53025 24 ipt_MASQUERADE,ip_nat_tftp,ip_nat_snmp_basic,ip_nat_sip,ip_nat_pptp,ip_nat_irc,ip_nat_h323,ip_nat_ftp,ip_nat_amanda,ip_conntrack_tftp,ip_conntrack_sip,ip_conntrack_pptp,ip_conntrack_irc,ip_conntrack_h323,ip_conntrack_ftp,ip_conntrack_amanda,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,ip_conntrack_netbios_ns,iptable_nat,ip_nat,xt_state ip_conntrack_amanda 8901 1 ip_nat_amanda ip_conntrack_ftp 11697 1 ip_nat_ftp ip_conntrack_h323 51677 1 ip_nat_h323 ip_conntrack_irc 10801 1 ip_nat_irc ip_conntrack_netbios_ns 6977 0 ip_conntrack_pptp 15441 1 ip_nat_pptp ip_conntrack_sip 11313 1 ip_nat_sip ip_conntrack_tftp 8249 1 ip_nat_tftp ip_nat 20973 12 ipt_SAME,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ip_nat_tftp,ip_nat_sip,ip_nat_pptp,ip_nat_irc,ip_nat_h323,ip_nat_ftp,ip_nat_amanda,iptable_nat ip_nat_amanda 6465 0 ip_nat_ftp 7361 0 ip_nat_h323 11201 0 ip_nat_irc 6721 0 ip_nat_pptp 9925 0 ip_nat_sip 8129 0 ip_nat_snmp_basic 13253 0 ip_nat_tftp 5953 0 iptable_filter 7105 1 iptable_mangle 6849 1 iptable_nat 11205 0 iptable_raw 6209 0 ip_tables 17029 4 iptable_raw,iptable_nat,iptable_mangle,iptable_filter ipt_addrtype 5953 4 ipt_ah 5953 0 ipt_CLUSTERIP 12357 0 ipt_dscp 5825 0 ipt_DSCP 6337 0 ipt_ecn 6337 0 ipt_ECN 7105 0 ipt_hashlimit 12745 0 ipt_iprange 5953 0 ipt_LOG 10177 2 ipt_MASQUERADE 7745 0 ipt_NETMAP 6209 0 ipt_owner 6081 0 ipt_recent 12497 0 ipt_REDIRECT 6209 0 ipt_REJECT 9537 4 ipt_SAME 6465 0 ipt_TCPMSS 8129 0 ipt_tos 5825 0 ipt_TOS 6337 0 ipt_ttl 5953 0 ipt_TTL 6337 0 ipt_ULOG 11717 0 xt_CLASSIFY 5953 0 xt_comment 5953 0 xt_connmark 6209 0 xt_CONNMARK 6465 0 xt_conntrack 6593 0 xt_dccp 7365 0 xt_helper 6593 0 xt_length 6081 0 xt_limit 6721 0 xt_mac 6081 0 xt_mark 5953 0 xt_MARK 6465 0 xt_multiport 7233 4 xt_NFQUEUE 6209 0 xt_physdev 6993 0 xt_pkttype 6081 0 xt_policy 7617 0 xt_state 6209 20 xt_tcpmss 6337 0 xt_tcpudp 7105 37 Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Extended Multi-port Match: Available Connection Tracking Match: Available Packet Type Match: Available Policy Match: Available Physdev Match: Available Physdev-is-bridged Support: Available Packet length Match: Available IP range Match: Available Recent Match: Available Owner Match: Available Ipset Match: Not available CONNMARK Target: Available Extended CONNMARK Target: Available Connmark Match: Available Extended Connmark Match: Available Raw Table: Available IPP2P Match: Not available CLASSIFY Target: Available Extended REJECT: Available Repeat match: Not available MARK Target: Available Extended MARK Target: Available Mangle FORWARD Chain: Available Comments: Available Address Type Match: Available TCPMSS Match: Available Hashlimit Match: Available NFQUEUE Target: Available Traffic Control Device eth0: qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 587410 bytes 2116 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 Device eth1: qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 308145 bytes 1746 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 TC Filters Device eth0: Device eth1: ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Jan 01, 2008 at 01:46:30PM -0500, Robert Moskowitz wrote:> Send that hugh listing? I guess I am jsut ''trained'' not to flood a list > with long dumps. Rather to be able to pull out the part(s) needed. > Well here goes: SSH into the firewall, dump > to file, gFTP to move the > dump here, gedit dump, cut to clipboard then paste! (simple :) ):Well, the steps do include compressing it first: c. /sbin/shorewall dump > /tmp/status.txt d. Post the /tmp/status.txt file as an attachment compressed with gzip or bzip2. e. Describe where you are trying to make the connection from (IP address) and what host (IP address) you are trying to connect to. I''ll take a look at it a little later when I get some time, that is if Tom or someone else doesn''t beat me to it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Robert Moskowitz wrote:> Roberto C. Sánchez wrote: >> On Tue, Jan 01, 2008 at 01:20:37PM -0500, Robert Moskowitz wrote: >> >>> Roberto C. Sánchez wrote: >>> >>>> On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote: >>>> >>>> >>>>> See anything obvious here? Other than wireshark on the firewall, how >>>>> might I figure out what is being blocked? All I get is a fast busy on a >>>>> call. >>>>> >>>>> >>>>> >>>> I would start with the output of ''shorewall dump''. >>>> >>> Will try. >>> >>>> But first, read this >>>> page: http://www.shorewall.net/support.htm >>>> >>> I did read it first. >>> >>> >> Sorry. Since the flowchart indicates that for your situation you should >> send the output of ''shorewall dump'' to the mailing list and you did not >> do that, I thought you had not read the page. Anyhow, once you forward >> the dump output you are more likely to get something resembling >> competent help. > Send that hugh listing? I guess I am jsut ''trained'' not to flood a list > with long dumps.The instructions point out that you can send the dump to support@shorewall.net rather than to the list.> Rather to be able to pull out the part(s) needed. > Well here goes: SSH into the firewall, dump > to file, gFTP to move the > dump here, gedit dump, cut to clipboard then paste! (simple :) ): >Unfortunately, that technique causes the dump to be spindled, folded and multilated by your mailer. At any rate, it appears that you have configured DROP policies but have not specified any logging. Consequently, you are depriving yourself of the best debugging tool available -- the log of dropped/rejected packets. So I would modify /etc/shorewall/policy to specify logging of any DROP/REJECT policies. You can then see what packets are being dropped by using the "shorewall show log" command. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> Robert Moskowitz wrote: > >> Roberto C. Sánchez wrote: >> >>> On Tue, Jan 01, 2008 at 01:20:37PM -0500, Robert Moskowitz wrote: >>> >>> >>>> Roberto C. Sánchez wrote: >>>> >>>> >>>>> On Tue, Jan 01, 2008 at 01:12:50PM -0500, Robert Moskowitz wrote: >>>>> >>>>> >>>>> >>>>>> See anything obvious here? Other than wireshark on the firewall, how >>>>>> might I figure out what is being blocked? All I get is a fast busy on a >>>>>> call. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I would start with the output of ''shorewall dump''. >>>>> >>>>> >>>> Will try. >>>> >>>> >>>>> But first, read this >>>>> page: http://www.shorewall.net/support.htm >>>>> >>>>> >>>> I did read it first. >>>> >>>> >>>> >>> Sorry. Since the flowchart indicates that for your situation you should >>> send the output of ''shorewall dump'' to the mailing list and you did not >>> do that, I thought you had not read the page. Anyhow, once you forward >>> the dump output you are more likely to get something resembling >>> competent help. >>> >> Send that hugh listing? I guess I am jsut ''trained'' not to flood a list >> with long dumps. >> > > The instructions point out that you can send the dump to > support@shorewall.net rather than to the list. >I am working too hard this day off. Not reading instructions all the way through. My dyslexia is no excuse in this case. sorrry.>> Rather to be able to pull out the part(s) needed. >> Well here goes: SSH into the firewall, dump > to file, gFTP to move the >> dump here, gedit dump, cut to clipboard then paste! (simple :) ): >> >> > Unfortunately, that technique causes the dump to be spindled, folded and > multilated by your mailer. >typical.> At any rate, it appears that you have configured DROP policies but have > not specified any logging.nope. logging can kill you if you don''tlog smart. Which I am not yet.> Consequently, you are depriving yourself of > the best debugging tool available -- the log of dropped/rejected > packets. So I would modify /etc/shorewall/policy to specify logging of > any DROP/REJECT policies. You can then see what packets are being > dropped by using the "shorewall show log" command. >Will change and test again! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Robert Moskowitz wrote:>I just got Shorewall up and running on a Centos box with the aid of Webmin. > >I have the luxury of 64 public addresses and thus both sides of this >firewall have routable addresses. No NATing! (I am a co-author of RFC >1918). > >This particular firewalls'' life purpose is protecting my Asterisk >servers (one is also an NTP server). I **thought** I was setting up the >rules right. It looks like I have a SIP registration with my VoIP >provider (Broadvoice), but calling is not working. Here is what I have: > >cat interfaces ># >Pub eth0 detect >VoIP eth1 detect > > >cat zones ># >fw firewall >Pub ipv4 # >VoIP ipv4 # > >cat cat rules ># >#SECTION ESTABLISHED >#SECTION RELATED >SECTION NEW >ACCEPT all all icmp >ACCEPT all all udp 53 >ACCEPT Pub VoIP tcp 80 >ACCEPT Pub VoIP tcp 443 ># SIP on UDP port 5060. Other SIP servers may need TCP port 5060 as well >ACCEPT all- all- udp 5004:5082I would suggest limiting that to just dport 5060.>ACCEPT all- all- tcp 5060I''ve never heard of SIP using TCP># RTP - the media stream >ACCEPT all- all- udp 10000:20000I would cut that down a bit - do you really need 10,000 simultaneous call capacity ! Don''t forget to alter /etc/asterisk/rtp.conf (IIRC) to suit. Also, start at 10001 not 10000 as that is used for Webmin.># IAX2- the IAX protocol >ACCEPT all- all- udp 4569 ># IAX - most have switched to IAX v2, or ought to >ACCEPT all- all- udp 5036Do you have AIX configured and in use - if not then I''d leave that rule out.> >See anything obvious here? Other than wireshark on the firewall, how >might I figure out what is being blocked? All I get is a fast busy on a >call.I would also suggest being more specific with your rules - all to all is generating rules for stuff you may not need/want. I personally favour listing specific servers unless there are a few - so only traffic to known servers gets allowed. The params file is useful for creating names that can be used in the rules files - eg $AstBoxes instead of listing Ip addresses.>On a related note, I want a low-overhead reporting on usage and >through-put on this firewall. The box is low end (per /proc/cpuinfo - >bogomips : 731.66, and 256Mb memory) and I don''t want to steal >cycles from the voice traffic to measure any firewall induced voice >degradation.See /etc/shorewall/accounting. You can quickly set up some rules to count traffic, and it''s then fairly simple to knock up a script to read the counters (I find "iptables -L account-ip -vxn" gives a reasonably parsable output), you may need to change account-ip to whatever your accounting chain is called. I feed the results into an rrd database and graph things from there. It doesn''t take a lot of overhead to do. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Jan 01, 2008 at 07:47:46PM +0000, Simon Hobson wrote:> >ACCEPT all- all- tcp 5060 > > I''ve never heard of SIP using TCPIt exists, and with proper QoS, usually works better. It is uncommon because UDP is easier to implement on a cheap hardware phone. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, 2008-01-01 at 13:12 -0500, Robert Moskowitz wrote:> > I have the luxury of 64 public addresses and thus both sides of this > firewall have routable addresses. No NATing! (I am a co-author of RFC > 1918).How ironic is it that a co-author of an RFC that if not expressly written for the purposes of, certainly is a linchpin to the usefulness of NAT doesn''t need/use it. :-) Bring on the IPV6 numbering/roll-out so that we can all (those who choose to anyway) stop writing and using braindead NAT tools. Now back to your regularly scheduled Shorewall channel. b. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
thanks for your help, below. Simon Hobson wrote:> Robert Moskowitz wrote: > >> I just got Shorewall up and running on a Centos box with the aid of Webmin. >> >> I have the luxury of 64 public addresses and thus both sides of this >> firewall have routable addresses. No NATing! (I am a co-author of RFC >> 1918). >> >> This particular firewalls'' life purpose is protecting my Asterisk >> servers (one is also an NTP server). I **thought** I was setting up the >> rules right. It looks like I have a SIP registration with my VoIP >> provider (Broadvoice), but calling is not working. Here is what I have: >> >> cat interfaces >> # >> Pub eth0 detect >> VoIP eth1 detect >> >> >> cat zones >> # >> fw firewall >> Pub ipv4 # >> VoIP ipv4 # >> >> cat cat rules >> # >> #SECTION ESTABLISHED >> #SECTION RELATED >> SECTION NEW >> ACCEPT all all icmp >> ACCEPT all all udp 53 >> ACCEPT Pub VoIP tcp 80 >> ACCEPT Pub VoIP tcp 443 >> # SIP on UDP port 5060. Other SIP servers may need TCP port 5060 as well >> ACCEPT all- all- udp 5004:5082 >> > > I would suggest limiting that to just dport 5060. >I got this from the wiki: http://www.voip-info.org/wiki-Asterisk+firewall+rules>> ACCEPT all- all- tcp 5060 >> > > I''ve never heard of SIP using TCP >It does. Part of the RFC. I should know, I attended enough of the meetings! And we are finally seeing SSL being used. Many worry about the TCP overhead for lots of SIP clients. But TCP has its advantages...>> # RTP - the media stream >> ACCEPT all- all- udp 10000:20000 >> > > I would cut that down a bit - do you really need 10,000 simultaneous > call capacity ! Don''t forget to alter /etc/asterisk/rtp.conf (IIRC) > to suit. Also, start at 10001 not 10000 as that is used for Webmin. >Yeah, well webmin uses TCP, not UDP? And those are the default ports, and no, only a few calls at a time!>> # IAX2- the IAX protocol >> ACCEPT all- all- udp 4569 >> # IAX - most have switched to IAX v2, or ought to >> ACCEPT all- all- udp 5036 >> > > Do you have AIX configured and in use - if not then I''d leave that rule out. >Free World Dialup for one. IAXmodem is of course localhost so the firewall should never see it.>> See anything obvious here? Other than wireshark on the firewall, how >> might I figure out what is being blocked? All I get is a fast busy on a >> call. >> > > I would also suggest being more specific with your rules - all to all > is generating rules for stuff you may not need/want. I personally > favour listing specific servers unless there are a few - so only > traffic to known servers gets allowed.Only thing(s) on the voipnet are Trixboxes. They are all duo-ported as well with all phones on the voipinnet. So the rules are for access to the firewall and to the Trixboxes only. Well one of them runs NTP. Oh, and Hylafax+ for efax so smtp is needed as well.> The params file is useful for > creating names that can be used in the rules files - eg $AstBoxes > instead of listing Ip addresses. >thanks but like I said, only asterisk boxes (Trixbox) on the internal net here.>> On a related note, I want a low-overhead reporting on usage and >> through-put on this firewall. The box is low end (per /proc/cpuinfo - >> bogomips : 731.66, and 256Mb memory) and I don''t want to steal >> cycles from the voice traffic to measure any firewall induced voice >> degradation. >> > > See /etc/shorewall/accounting. > > You can quickly set up some rules to count traffic, and it''s then > fairly simple to knock up a script to read the counters (I find > "iptables -L account-ip -vxn" gives a reasonably parsable output), > you may need to change account-ip to whatever your accounting chain > is called. I feed the results into an rrd database and graph things > from there. > > It doesn''t take a lot of overhead to do.thanks. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> On Tue, Jan 01, 2008 at 07:47:46PM +0000, Simon Hobson wrote: > >>> ACCEPT all- all- tcp 5060 >>> >> I''ve never heard of SIP using TCP >> > > It exists, and with proper QoS, usually works better. It is uncommon > because UDP is easier to implement on a cheap hardware phone.also good for SIP trunking between divisions. I think Avaya uses it. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Boy do I need to go out in the snow-covered streets for a walk to clear my head. All the time my testing was dialing the WRONG number. Of course I was NOT seeing any traffic. Nothing in the Shorewall logs. Wireshark did not capture any packets from Broadvoice. Finally logged into my Broadvoice account, and it did not show any incoming calls. hmmm. Checked the logs in my cell phone (what I was using for the test), and my dyslexia bit me again. So testing with the proper number and: Simon Hobson wrote:> Robert Moskowitz wrote: > >> # SIP on UDP port 5060. Other SIP servers may need TCP port 5060 as well >> ACCEPT all- all- udp 5004:5082 >> > > I would suggest limiting that to just dport 5060. > > >> ACCEPT all- all- tcp 5060 >> > > I''ve never heard of SIP using TCP > > >> # RTP - the media stream >> ACCEPT all- all- udp 10000:20000 >> > > I would cut that down a bit - do you really need 10,000 simultaneous > call capacity ! Don''t forget to alter /etc/asterisk/rtp.conf (IIRC) > to suit. Also, start at 10001 not 10000 as that is used for Webmin. >call works just fine. Now to add in the accounting. But probably first to install the final production version of Trixbox 2.4 that was released today! Thanks for all of your help here. I will probably be back in a few days! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
I have 2 interfaces: Pub and VoIP I need to allow port 80 into VoIP (FreePBX functions), and 80 out (yum updates), so I have the rules: ACCEPT Pub VoIP tcp 80 ACCEPT VoIP Pub tcp 80 ACCEPT fw Pub tcp 80 Seems this can be expressed in one rule: ACCEPT all all- tcp 80 Is the one rule ''faster'' than the three? Which has greater ''clarity''? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Robert Moskowitz wrote:> I have 2 interfaces: Pub and VoIP > > I need to allow port 80 into VoIP (FreePBX functions), and 80 out (yum > updates), so I have the rules: > > ACCEPT Pub VoIP tcp 80 > ACCEPT VoIP Pub tcp 80 > ACCEPT fw Pub tcp 80 > > > Seems this can be expressed in one rule: > > ACCEPT all all- tcp 80 > > > Is the one rule ''faster'' than the three?No -- Shorewall expands the one rule into three.> Which has greater ''clarity''?I think that clarity is in the eye of the beholder. Use whichever is clearer to you. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> Robert Moskowitz wrote: >> I have 2 interfaces: Pub and VoIP >> >> I need to allow port 80 into VoIP (FreePBX functions), and 80 out (yum >> updates), so I have the rules: >> >> ACCEPT Pub VoIP tcp 80 >> ACCEPT VoIP Pub tcp 80 >> ACCEPT fw Pub tcp 80 >> >> >> Seems this can be expressed in one rule: >> >> ACCEPT all all- tcp 80 >> >> >> Is the one rule ''faster'' than the three? > > No -- Shorewall expands the one rule into three. >Actually, it expands into 4 rules: Pub->Voip Voip->Pub fw->Voip fw->Pub -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> Tom Eastep wrote: > >> Robert Moskowitz wrote: >> >>> I have 2 interfaces: Pub and VoIP >>> >>> I need to allow port 80 into VoIP (FreePBX functions), and 80 out (yum >>> updates), so I have the rules: >>> >>> ACCEPT Pub VoIP tcp 80 >>> ACCEPT VoIP Pub tcp 80 >>> ACCEPT fw Pub tcp 80 >>> >>> >>> Seems this can be expressed in one rule: >>> >>> ACCEPT all all- tcp 80 >>> >>> >>> Is the one rule ''faster'' than the three? >>> >> No -- Shorewall expands the one rule into three. >> >> > > Actually, it expands into 4 rules: > > Pub->Voip > Voip->Pub > fw->Voip > fw->PubAnd thus another exercise in the danger of too general of a rule. The fw->VoIP does not hurt; in this case. But we see the point.... So now I will go over my general rules. Where I need bi-directional session initiation, I have used the form: ACCEPT all- all- {tcp|udp} <port list> this does seem to only expand to the rules: ACCEPT Pub VoIP {tcp|udp} <port list> ACCEPT VoIP Pub {tcp|udp} <port list> ..... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/