Hi, I need some help in this problem: I am having this problem: I have my vpn client with openvpn and my shorewall fireall at work with openvpn server (in the same server) Now, I need to route my vpn client traffic to this IP:74.53.205.xxx to be routed to my shorewall firewall because I accept connectios on that server only from my shorewall external Ip. The problem is that when I configure my server.conf (openvpn) to push "route 74.53.205.xxx 255.255.255.255" to the client, I cant access that server. What is wrong in my conf?? I have shorewall Shorewall-perl 4.0.3 My interface configuration is: eth0:200.40.xx.xx (internet) eth1:201.221.xx.xx (internet) eth2:172.16.10.1 (dmz) eth3:192.168.0.4 (lan) tun0: 10.8.0.1 (vpn) Files:Interfaces net eth1 detect norfc1918 net eth0 detect norfc1918 loc eth3 detect dmz eth2 detect vpn tun0 Zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4 vpn ipv4 Masq #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth1 192.168.0.0/24 201.221.xx.xx eth1 172.16.10.0/24 201.221.xx.xx eth1 10.8.0.0/24 201.221.xx.xx eth0 192.168.0.0/24 200.40.xx.xx eth0 172.16.10.0/24 200.40.xx.xx Policy #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT dmz loc ACCEPT info dmz net DROP info net all DROP all all REJECT info vpn net ACCEPT info vpn fw ACCEPT info Providers #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ded 1 1 main eth1 201.221.xx.xx track eth2,eth3 net 2 2 main eth0 200.40.xx.xx track eth2,eth3 Rules ACCEPT:info vpn net tcp http,https Tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:1194 net 0.0.0.0/0 OPENVPN: Server.conf push "route 74.53.205.xxx 255.255.255.255" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hi, I need some help in this problem: I am having this problem: I have my vpn client with openvpn and my shorewall fireall at work with openvpn server (in the same server) Now, I need to route my vpn client traffic to this IP:74.53.205.xxx to be routed to my shorewall firewall because I accept connectios on that server only from my shorewall external Ip. The problem is that when I configure my server.conf (openvpn) to push "route 74.53.205.xxx 255.255.255.255" to the client, I cant access that server. What is wrong in my conf?? I have shorewall Shorewall-perl 4.0.3 My interface configuration is: eth0:200.40.xx.xx (internet) eth1:201.221.xx.xx (internet) eth2:172.16.10.1 (dmz) eth3:192.168.0.4 (lan) tun0: 10.8.0.1 (vpn) Files:Interfaces net eth1 detect norfc1918 net eth0 detect norfc1918 loc eth3 detect dmz eth2 detect vpn tun0 Zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4 vpn ipv4 Masq #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth1 192.168.0.0/24 201.221.xx.xx eth1 172.16.10.0/24 201.221.xx.xx eth1 10.8.0.0/24 201.221.xx.xx eth0 192.168.0.0/24 200.40.xx.xx eth0 172.16.10.0/24 200.40.xx.xx Policy #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT dmz loc ACCEPT info dmz net DROP info net all DROP all all REJECT info vpn net ACCEPT info vpn fw ACCEPT info Providers #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ded 1 1 main eth1 201.221.xx.xx track eth2,eth3 net 2 2 main eth0 200.40.xx.xx track eth2,eth3 Rules ACCEPT:info vpn net tcp http,https Tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:1194 net 0.0.0.0/0 OPENVPN: Server.conf push "route 74.53.205.xxx 255.255.255.255" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hi, Nico Pagliaro wrote:> Hi, I need some help in this problem: > I am having this problem: > > I have my vpn client with openvpn and my shorewall fireall at work with > openvpn > server (in the same server) > Now, I need to route my vpn client traffic to this IP:74.53.205.xxx to be > routed > to my shorewall firewall because I accept connectios on that server only > from > my shorewall external Ip. > The problem is that when I configure my server.conf (openvpn) to push > "route 74.53.205.xxx 255.255.255.255" to the client, I cant access that > server. > What is wrong in my conf?? > > > I have shorewall Shorewall-perl 4.0.3 > My interface configuration is: > eth0:200.40.xx.xx (internet) > eth1:201.221.xx.xx (internet) > eth2:172.16.10.1 (dmz) > eth3:192.168.0.4 (lan) > tun0: 10.8.0.1 (vpn) > > Files:Interfaces > net eth1 detect norfc1918 > net eth0 detect norfc1918 > loc eth3 detect > dmz eth2 detect > vpn tun0 > > Zones: > #ZONE TYPE OPTIONS IN OUT > # OPTIONS OPTIONS > fw firewall > net ipv4 > loc ipv4 > dmz ipv4 > vpn ipv4 > > Masq > #INTERFACE SOURCE ADDRESS PROTO PORT(S) > IPSEC MARK > eth1 192.168.0.0/24 201.221.xx.xx > eth1 172.16.10.0/24 201.221.xx.xx > eth1 10.8.0.0/24 201.221.xx.xx > eth0 192.168.0.0/24 200.40.xx.xx > eth0 172.16.10.0/24 200.40.xx.xx > > Policy > #SOURCE DEST POLICY LOG LIMIT:BURST > # LEVEL > loc net ACCEPT > dmz loc ACCEPT info > dmz net DROP info > net all DROP > all all REJECT info > vpn net ACCEPT info > vpn fw ACCEPT info >I''d list the vpn policy before the drop/reject policy here.> Providers > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY > OPTIONS COPY > ded 1 1 main eth1 201.221.xx.xx > track eth2,eth3Without a shorewall dump this is a just a guess, but my gut feeling is that there is no route from the 10.8.0.0/24 subnet, in the provider''s routing table. If you want tun0 to be able to pass traffic to this provider, think you need tun0 added to the copy column.> net 2 2 main eth0 200.40.xx.xx > track eth2,eth3 > > > Rules > ACCEPT:info vpn net tcp http,https > >If you fix the policy above then this is not required, or change the policy to reject to make this rule effective.> Tunnels: > #TYPE ZONE GATEWAY GATEWAY > # ZONE > openvpnserver:1194 net 0.0.0.0/0 > > > > > > OPENVPN: Server.conf > push "route 74.53.205.xxx 255.255.255.255" >In tcrules add: 1:P tun0 74.53.205.xxx tcp http,https - - route_rules file come into play here also, did you use the example from the bottom of http://www.shorewall.net/MultiISP.html? That is why a shorewall dump is important, give a great overall view of the network setup you have, without guessing what the whole layout is. If that doesn''t work please provide a shorewall dump. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> Hi, I need some help in this problem: > I am having this problem: > > I have my vpn client with openvpn and my shorewall fireall at work with > openvpn > server (in the same server) > Now, I need to route my vpn client traffic to this IP:74.53.205.xxx to > be routed > to my shorewall firewall because I accept connectios on that server only > from > my shorewall external Ip. > The problem is that when I configure my server.conf (openvpn) to push > "route 74.53.205.xxx 255.255.255.255 <http://255.255.255.255>" to the > client, I cant access that server. > What is wrong in my conf??It sounds to me like you are trying to push a route to the VPN server to go through the VPN connection -- that can never work! You are asking your system to route the encrypted VPN packets through the VPN itself. To confirm: a) shorewall clear b) Connect to your VPN server. I''m guessing that it still doesn''t work indicating that your problem has nothing to do with Shorewall. c) Be sure to "shorewall start" after the test. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Nico Pagliaro wrote: >> Hi, I need some help in this problem: >> I am having this problem: >> >> I have my vpn client with openvpn and my shorewall fireall at work with >> openvpn >> server (in the same server) >> Now, I need to route my vpn client traffic to this IP:74.53.205.xxx to >> be routed >> to my shorewall firewall because I accept connectios on that server only >> from >> my shorewall external Ip. >> The problem is that when I configure my server.conf (openvpn) to push >> "route 74.53.205.xxx 255.255.255.255 <http://255.255.255.255>" to the >> client, I cant access that server. >> What is wrong in my conf?? > > It sounds to me like you are trying to push a route to the VPN server to go > through the VPN connection -- that can never work! You are asking your > system to route the encrypted VPN packets through the VPN itself.Tom: The openvpn tunnel, based on the masq entries, appears to be to 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by the tunnels file entry. Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears that Nico wants to have the traffic from the vpn client to 74.53.205.xxx appear to come from the fw/vpn-server''s 201.221.xx.xx. address, that would explain the push route in openvpn. I think this is what Nico wants: from the vpn-client to 74.53.205.xxx: vpn-client (with host route) -> tunnel -> fw/vpn-server -> masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx from 74.53.205.xxx to the vpn-client: 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq -> tunnel -> vpn-client Nico: Could you clarify this for us please. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Jerry Vonau wrote:> > The openvpn tunnel, based on the masq entries, appears to be to > 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by > the tunnels file entry. > > Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears > that Nico wants to have the traffic from the vpn client to 74.53.205.xxx > appear to come from the fw/vpn-server''s 201.221.xx.xx. > address, that would explain the push route in openvpn. > > I think this is what Nico wants: > > from the vpn-client to 74.53.205.xxx: > vpn-client (with host route) -> tunnel -> fw/vpn-server -> > masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx > > from 74.53.205.xxx to the vpn-client: > 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq -> > tunnel -> vpn-client > > Nico: > > Could you clarify this for us please. >If that is indeed the case then your tip about the route_rules example in the Multi-ISP doc should solve the problem. The cause of the failure is that return traffic from 74.53.205.xxx is mis-routed. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Jerry Vonau wrote: > >> The openvpn tunnel, based on the masq entries, appears to be to >> 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by >> the tunnels file entry. >> >> Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears >> that Nico wants to have the traffic from the vpn client to 74.53.205.xxx >> appear to come from the fw/vpn-server''s 201.221.xx.xx. >> address, that would explain the push route in openvpn. >> >> I think this is what Nico wants: >> >> from the vpn-client to 74.53.205.xxx: >> vpn-client (with host route) -> tunnel -> fw/vpn-server -> >> masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx >> >> from 74.53.205.xxx to the vpn-client: >> 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq -> >> tunnel -> vpn-client >> >> Nico: >> >> Could you clarify this for us please. >> > > If that is indeed the case then your tip about the route_rules example in > the Multi-ISP doc should solve the problem. The cause of the failure is that > return traffic from 74.53.205.xxx is mis-routed. >I agree, but there would be no route in the providers table for tun0. If I recall correctly, no route in the ip table, no traffic, otherwise we would not have to list the masq lan in the copy column. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Jerry Vonau wrote:> Tom Eastep wrote: >> Jerry Vonau wrote: >> >>> The openvpn tunnel, based on the masq entries, appears to be to >>> 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by >>> the tunnels file entry. >>> >>> Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears >>> that Nico wants to have the traffic from the vpn client to 74.53.205.xxx >>> appear to come from the fw/vpn-server''s 201.221.xx.xx. >>> address, that would explain the push route in openvpn. >>> >>> I think this is what Nico wants: >>> >>> from the vpn-client to 74.53.205.xxx: >>> vpn-client (with host route) -> tunnel -> fw/vpn-server -> >>> masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx >>> >>> from 74.53.205.xxx to the vpn-client: >>> 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq -> >>> tunnel -> vpn-client >>> >>> Nico: >>> >>> Could you clarify this for us please. >>> >> If that is indeed the case then your tip about the route_rules example in >> the Multi-ISP doc should solve the problem. The cause of the failure is that >> return traffic from 74.53.205.xxx is mis-routed. >> > > I agree, but there would be no route in the providers table for tun0. If > I recall correctly, no route in the ip table, no traffic, otherwise we > would not have to list the masq lan in the copy column.Placing tun0 in the COPY column would require that OpenVPN be started before Shorewall; the distributions start Shorewall before OpenVPN. By routing all traffic to the VPN network using the main routing table (using an entry in route_rules), we avoid that dependency. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Yes, thats right!! And it works!!! the only thing that I was missing is to copy tun0 interface in providers. Now, this work fine in my lab, but in production I have another Shorewall (older) 3.4.2 and i have made the same, but with non luck ;( look, when I try from my client to my dmz in the log appear kernel: Shorewall:nic2dmz:ACCEPT:IN=tun0 OUT=eth0 SRC=10.8.0.13 DST192.168.0.15 LEN (note that nic(nico) is openvpn zone) There is no problem between internal zones, BUT if I try to go to my server 74.53.205.xxx log this:_ kernel: Shorewall:all2all:REJECT:IN=tun0 OUT=eth2 SRC=10.8.0.13 DST74.54.56.xxx It sounds like there ir no policy that apply, but in my policie file I have nic net ACCEPT info nic fw ACCEPT info nic loc ACCEPT info nic dmz ACCEPT info ZONES: fw firewall cue ipv4 adm ipv4 dmz ipv4 p2p ipv4 vpn ipv4 loc ipv4 net ipv4 nic ipv4 Interfaces: nic tun0 - - eth0 detect proxyarp net eth1 detect norfc1918 net eth2 detect norfc1918 Providers ded 1 1 main eth1 $ETH1_GW track,balance eth0,tun0 ngt 2 2 main eth2 $ETH2_GW track,balance eth0,tun0 RULES: ACCEPT nic net tcp ssh,http ACCEPT nic loc all Any Idea? On 10/9/07, Tom Eastep <teastep@shorewall.net> wrote:> > Jerry Vonau wrote: > > > > > The openvpn tunnel, based on the masq entries, appears to be to > > 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by > > the tunnels file entry. > > > > Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears > > that Nico wants to have the traffic from the vpn client to 74.53.205.xxx > > appear to come from the fw/vpn-server''s 201.221.xx.xx. > > address, that would explain the push route in openvpn. > > > > I think this is what Nico wants: > > > > from the vpn-client to 74.53.205.xxx: > > vpn-client (with host route) -> tunnel -> fw/vpn-server -> > > masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx > > > > from 74.53.205.xxx to the vpn-client: > > 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq -> > > tunnel -> vpn-client > > > > Nico: > > > > Could you clarify this for us please. > > > > If that is indeed the case then your tip about the route_rules example in > the Multi-ISP doc should solve the problem. The cause of the failure is > that > return traffic from 74.53.205.xxx is mis-routed. > > -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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Jerry Vonau wrote: >> Tom Eastep wrote: >>> Jerry Vonau wrote:<snip>>>>> >>> If that is indeed the case then your tip about the route_rules example in >>> the Multi-ISP doc should solve the problem. The cause of the failure is that >>> return traffic from 74.53.205.xxx is mis-routed. >>> >> I agree, but there would be no route in the providers table for tun0. If >> I recall correctly, no route in the ip table, no traffic, otherwise we >> would not have to list the masq lan in the copy column. > > Placing tun0 in the COPY column would require that OpenVPN be started before > Shorewall; the distributions start Shorewall before OpenVPN. By routing all > traffic to the VPN network using the main routing table (using an entry in > route_rules), we avoid that dependency. >It''s not the "to the VPN network" that will be the issue, it''s the "from the vpn network to the net" that will be the issue. If you don''t use the copy column at all, traffic flows, but you end up with the "martian issue" and other strangeness. If you don''t list your "to be masq''d interfaces" in the copy column no traffic flows from the "to be masq''d" to the net. Sounds like a catch22 to me, unless you have the openvpn init script add that route to the provider''s table. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> Yes, thats right!! > And it works!!! the only thing that I was missing is to copy tun0 interface > in providers. > > Now, this work fine in my lab, but in production I have another Shorewall > (older) 3.4.2 and i have made the same, but with non luck ;( > look, when I try from my client to my dmz in the log appear > kernel: Shorewall:nic2dmz:ACCEPT:IN=tun0 OUT=eth0 SRC=10.8.0.13 DST> 192.168.0.15 LEN > (note that nic(nico) is openvpn zone) > There is no problem between internal zones, BUT if I try to go to my server > 74.53.205.xxx > log this:_ > kernel: Shorewall:all2all:REJECT:IN=tun0 OUT=eth2 SRC=10.8.0.13 DST> 74.54.56.xxx > > It sounds like there ir no policy that apply, but in my policie file I have > nic net ACCEPT info > nic fw ACCEPT info > nic loc ACCEPT info > nic dmz ACCEPT info >Those are above the drop/reject policy and not below right? Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
############################################################################### #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL nic net ACCEPT info nic fw ACCEPT info nic loc ACCEPT info nic dmz ACCEPT info fw all ACCEPT - dmz all ACCEPT - loc loc ACCEPT - loc fw ACCEPT - p2p fw ACCEPT - fw p2p ACCEPT - #loc all ACCEPT - #dmz all ACCEPT - #vpn all ACCEPT - #cue all ACCEPT - # vpn loc vpn ACCEPT - vpn loc ACCEPT - dmz vpn ACCEPT - vpn dmz ACCEPT - vpn fw ACCEPT - vpn net ACCEPT - p2p vpn ACCEPT - vpn p2p ACCEPT - fw vpn ACCEPT - # cue loc cue ACCEPT - cue loc ACCEPT - dmz cue ACCEPT - #cue dmz ACCEPT - #cue fw ACCEPT - #fw cue ACCEPT - p2p cue ACCEPT - #cue p2p ACCEPT - # resto del mundo #net net DROP net all DROP info # THE FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- DO NOT REMOVE On 10/9/07, Jerry Vonau <jvonau@shaw.ca> wrote:> > Nico Pagliaro wrote: > > Yes, thats right!! > > And it works!!! the only thing that I was missing is to copy tun0 > interface > > in providers. > > > > Now, this work fine in my lab, but in production I have another > Shorewall > > (older) 3.4.2 and i have made the same, but with non luck ;( > > look, when I try from my client to my dmz in the log appear > > kernel: Shorewall:nic2dmz:ACCEPT:IN=tun0 OUT=eth0 SRC=10.8.0.13 DST> > 192.168.0.15 LEN > > (note that nic(nico) is openvpn zone) > > There is no problem between internal zones, BUT if I try to go to my > server > > 74.53.205.xxx > > log this:_ > > kernel: Shorewall:all2all:REJECT:IN=tun0 OUT=eth2 SRC=10.8.0.13 DST> > 74.54.56.xxx > > > > It sounds like there ir no policy that apply, but in my policie file I > have > > nic net ACCEPT info > > nic fw ACCEPT info > > nic loc ACCEPT info > > nic dmz ACCEPT info > > > Those are above the drop/reject policy and not below right? > > Jerry > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Jerry Vonau wrote:> > It''s not the "to the VPN network" that will be the issue, it''s the "from > the vpn network to the net" that will be the issue. > > If you don''t use the copy column at all, traffic flows, but you end up > with the "martian issue" and other strangeness.If you don''t route filter traffic from tun*, there shouldn''t be any problems.> > If you don''t list your "to be masq''d interfaces" in the copy column no > traffic flows from the "to be masq''d" to the net. > > Sounds like a catch22 to me, unless you have the openvpn init script add > that route to the provider''s table. >I currently include ''tun*'' in my COPY column but I didn''t always. I have a requirement similar to Nico in that some sites at my ISP can only be accessed when the SOURCE IP is owned by the ISP. The first time that I tried routing one of those sites through OpenVPN it didn''t work; a few minutes with tcpdump showed me that traffic was leaving my system OK but return packets were being routed back out to the net interface rather than through the OpenVPN tunnel. Adding the route rule solved the problem without adding tun0 to the COPY column. Note: Although I only have one Internet connection, I use a Multi-ISP configuration so that I exercise that part of Shorewall on my own setup. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> ############################################################################### > #SOURCE DEST POLICY LOG LIMIT:BURST > # LEVEL > nic net ACCEPT info > nic fw ACCEPT info > nic loc ACCEPT info > nic dmz ACCEPT info > fw all ACCEPT - > dmz all ACCEPT - > loc loc ACCEPT - > loc fw ACCEPT - > p2p fw ACCEPT - > fw p2p ACCEPT - > #loc all ACCEPT - > #dmz all ACCEPT - > #vpn all ACCEPT - > #cue all ACCEPT - > # vpn > loc vpn ACCEPT - > vpn loc ACCEPT - > dmz vpn ACCEPT - > vpn dmz ACCEPT - > vpn fw ACCEPT - > vpn net ACCEPT - > p2p vpn ACCEPT - > vpn p2p ACCEPT - > fw vpn ACCEPT - > # cue > loc cue ACCEPT - > cue loc ACCEPT - > dmz cue ACCEPT - > #cue dmz ACCEPT - > #cue fw ACCEPT - > #fw cue ACCEPT - > p2p cue ACCEPT - > #cue p2p ACCEPT - > # resto del mundo > #net net DROP > net all DROP info > # THE FOLLOWING POLICY MUST BE LAST > all all REJECT info > #LAST LINE -- DO NOT REMOVE > >OK, I''m not sure... There has been a few changes since 3.4.2. I just can''t recall if there were any issues or changes that might be the cause the difference in behavior. A dump would be your best bet here. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Great, can you tell me how to do dump? just shorewall dump > file On 10/9/07, Jerry Vonau <jvonau@shaw.ca> wrote:> > Nico Pagliaro wrote: > > > ############################################################################### > > #SOURCE DEST POLICY LOG > LIMIT:BURST > > # LEVEL > > nic net ACCEPT info > > nic fw ACCEPT info > > nic loc ACCEPT info > > nic dmz ACCEPT info > > fw all ACCEPT - > > dmz all ACCEPT - > > loc loc ACCEPT - > > loc fw ACCEPT - > > p2p fw ACCEPT - > > fw p2p ACCEPT - > > #loc all ACCEPT - > > #dmz all ACCEPT - > > #vpn all ACCEPT - > > #cue all ACCEPT - > > # vpn > > loc vpn ACCEPT - > > vpn loc ACCEPT - > > dmz vpn ACCEPT - > > vpn dmz ACCEPT - > > vpn fw ACCEPT - > > vpn net ACCEPT - > > p2p vpn ACCEPT - > > vpn p2p ACCEPT - > > fw vpn ACCEPT - > > # cue > > loc cue ACCEPT - > > cue loc ACCEPT - > > dmz cue ACCEPT - > > #cue dmz ACCEPT - > > #cue fw ACCEPT - > > #fw cue ACCEPT - > > p2p cue ACCEPT - > > #cue p2p ACCEPT - > > # resto del mundo > > #net net DROP > > net all DROP info > > # THE FOLLOWING POLICY MUST BE LAST > > all all REJECT info > > #LAST LINE -- DO NOT REMOVE > > > > > > OK, I''m not sure... There has been a few changes since 3.4.2. I just > can''t recall if there were any issues or changes that might be the cause > the difference in behavior. A dump would be your best bet here. > > Jerry > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> Great, can you tell me how to do dump? just shorewall dump > filehttp://www.shorewall.net/support.htm#Guidelines -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > Ok, I am sending the sump file, but look what I have tested. I put in the > policy file > nic all ACCEPT info > > and now works!! so I think that my problem is that the policy > nic net ACCEPT doesnt work! so my net zone its ok???? > > On 10/9/07, Tom Eastep < teastep@shorewall.net> wrote: > > > > Nico Pagliaro wrote: > > > Great, can you tell me how to do dump? just shorewall dump > file > > > > http://www.shorewall.net/support.htm#Guidelines > > > > -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: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > > > > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> > > > Ok, I am sending the sump file, but look what I have tested. I put > in the policy file > nic all ACCEPT info > > and now works!! so I think that my problem is that the policy > nic net ACCEPT doesnt work! so my net zone its ok????It looks like the 74.53.xxx.xxx addresses are in the ''adm'' zone, not the ''net'' zone. As an aside, with your configuration you *really* should update to Shorewall 3.4 or later (4.0.4 with Shorewall-perl preferred) and set OPTIMIZE=1 in shorewall.conf. Your ruleset would be a lot smaller. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Well, I think the same and that´s why I have a lab ready to go.- Can I update my firewall 3 to 4.0.4? or its complicated? On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote:> > Nico Pagliaro wrote: > > > > > > > > Ok, I am sending the sump file, but look what I have tested. I put > > in the policy file > > nic all ACCEPT info > > > > and now works!! so I think that my problem is that the policy > > nic net ACCEPT doesnt work! so my net zone its ok???? > > It looks like the 74.53.xxx.xxx addresses are in the 'adm' zone, not the > 'net' zone. > > As an aside, with your configuration you *really* should update to > Shorewall > 3.4 or later (4.0.4 with Shorewall-perl preferred) and set OPTIMIZE=1 in > shorewall.conf. Your ruleset would be a lot smaller. > > -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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
What is the propose of the flag OPTIMEZE? On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote:> > Nico Pagliaro wrote: > > > > > > > > Ok, I am sending the sump file, but look what I have tested. I put > > in the policy file > > nic all ACCEPT info > > > > and now works!! so I think that my problem is that the policy > > nic net ACCEPT doesnt work! so my net zone its ok???? > > It looks like the 74.53.xxx.xxx addresses are in the ''adm'' zone, not the > ''net'' zone. > > As an aside, with your configuration you *really* should update to > Shorewall > 3.4 or later (4.0.4 with Shorewall-perl preferred) and set OPTIMIZE=1 in > shorewall.conf. Your ruleset would be a lot smaller. > > -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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> Well, I think the same and that´s why I have a lab ready to go.- > Can I update my firewall 3 to 4.0.4? or its complicated?See the release notes at http://www1.shorewall.net/pub/shorewall/4.0/shorewall-4.0.4/releasenotes.txt -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> What is the propose of the flag OPTIMEZE?http://www.shorewall.net/manpages/shorewall.conf.html -Tom> > On 10/10/07, *Tom Eastep* <teastep@shorewall.net > <mailto:teastep@shorewall.net>> wrote: > > Nico Pagliaro wrote: > > > > > > > > Ok, I am sending the sump file, but look what I have tested. I > put > > in the policy file > > nic all ACCEPT info > > > > and now works!! so I think that my problem is that the policy > > nic net ACCEPT doesnt work! so my net zone its ok???? > > It looks like the 74.53.xxx.xxx addresses are in the ''adm'' zone, not the > ''net'' zone. > > As an aside, with your configuration you *really* should update to > Shorewall > 3.4 or later (4.0.4 with Shorewall-perl preferred) and set > OPTIMIZE=1 in > shorewall.conf. Your ruleset would be a lot smaller. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net <mailto:teastep@shorewall.net> > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote:> Nico Pagliaro wrote: > > What is the propose of the flag OPTIMEZE? > > http://www.shorewall.net/manpages/shorewall.conf.html > > -Tom >So, i''ve read the definition of the OPTIMIZE flag: These extra rules can be eliminated by setting OPTIMIZE=1. The OPTIMIZE setting also controls the suppression of redundant wildcard rules (those specifying "all" in the SOURCE or DEST column). A wildcard rule is considered to be redundant when it has the same ACTION and Log Level as the applicable policy. What reason would we want to leave this at 0? Why is this an option? Wouldn''t you always want it optimized? Just Curious, Thanks Brad B. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Brad Bendily wrote:> On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote: >> Nico Pagliaro wrote: >>> What is the propose of the flag OPTIMEZE? >> http://www.shorewall.net/manpages/shorewall.conf.html >> >> -Tom >> > So, i''ve read the definition of the OPTIMIZE flag: > These extra rules can be eliminated by setting OPTIMIZE=1. > The OPTIMIZE setting also controls the suppression of redundant > wildcard rules (those specifying "all" in the SOURCE or DEST column). > A wildcard rule is considered to be redundant when it has the same > ACTION and Log Level as the applicable policy. > > What reason would we want to leave this at 0? Why is this an option? > Wouldn''t you always want it optimized?Making it unconditional could have broken existing configurations. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Brad Bendily wrote: >> On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote: >>> Nico Pagliaro wrote: >>>> What is the propose of the flag OPTIMEZE? >>> http://www.shorewall.net/manpages/shorewall.conf.html >>> >>> -Tom >>> >> So, i''ve read the definition of the OPTIMIZE flag: >> These extra rules can be eliminated by setting OPTIMIZE=1. >> The OPTIMIZE setting also controls the suppression of redundant >> wildcard rules (those specifying "all" in the SOURCE or DEST column). >> A wildcard rule is considered to be redundant when it has the same >> ACTION and Log Level as the applicable policy. >> >> What reason would we want to leave this at 0? Why is this an option? >> Wouldn''t you always want it optimized? > > Making it unconditional could have broken existing configurations.Example: Policy: #SOURCE DEST POLICY loc fw ACCEPT #ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ... ACCEPT loc:192.168.1.4 all tcp 22 REJECT loc fw tcp 22 Since the ACCEPT rule duplicates the policy for loc->fw, the loc->fw ACCEPT rule is not generated under OPTIMIZE=1. As a result, 192.168.1.4 can no longer connect to the firewall using SSH. The solution is to modify the ACCEPT rule: #ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ... ACCEPT! loc:192.168.1.4 all tcp 22 REJECT loc fw tcp 22 -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
I dont have undestand at all the example, why 192.168.1.4 wont connect to the fw? because it have "all" in the rule? On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote:> > Tom Eastep wrote: > > Brad Bendily wrote: > >> On 10/10/07, Tom Eastep <teastep@shorewall.net> wrote: > >>> Nico Pagliaro wrote: > >>>> What is the propose of the flag OPTIMEZE? > >>> http://www.shorewall.net/manpages/shorewall.conf.html > >>> > >>> -Tom > >>> > >> So, i''ve read the definition of the OPTIMIZE flag: > >> These extra rules can be eliminated by setting OPTIMIZE=1. > >> The OPTIMIZE setting also controls the suppression of redundant > >> wildcard rules (those specifying "all" in the SOURCE or DEST column). > >> A wildcard rule is considered to be redundant when it has the same > >> ACTION and Log Level as the applicable policy. > >> > >> What reason would we want to leave this at 0? Why is this an option? > >> Wouldn''t you always want it optimized? > > > > Making it unconditional could have broken existing configurations. > > Example: > > Policy: > #SOURCE DEST POLICY > loc fw ACCEPT > > #ACTION SOURCE DEST PROTO DEST SOURCE > > # PORT PORT(S) > ... > ACCEPT loc:192.168.1.4 all tcp 22 > REJECT loc fw tcp 22 > > > Since the ACCEPT rule duplicates the policy for loc->fw, the loc->fw > ACCEPT rule is not generated under OPTIMIZE=1. As a result, 192.168.1.4 > can no longer connect to the firewall using SSH. > > The solution is to modify the ACCEPT rule: > > #ACTION SOURCE DEST PROTO DEST SOURCE > > # PORT PORT(S) > ... > ACCEPT! loc:192.168.1.4 all tcp 22 > REJECT loc fw tcp 22 > > -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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Nico Pagliaro wrote:> I dont have undestand at all the example, why 192.168.1.4 > <http://192.168.1.4> wont connect to the fw? because it have "all" in > the rule?Nico -- please don''t top-post.> Example: > > Policy: > #SOURCE DEST POLICY > loc fw ACCEPT > > #ACTION SOURCE DEST PROTO DEST SOURCE > > # PORT PORT(S) > ... > ACCEPT loc:192.168.1.4 all > tcp 22 > REJECT loc fw tcp 22Let''s assume that the zones file is: fw firewall net ipv4 loc ipv4 dmz ipv4 When processing the first rule above, the Shorewall compiler expands it into three rules: ACCEPT loc:192.168.1.4 fw ACCEPT loc:192.168.1.4 net ACCEPT loc:192.168.1.4 dmz It does not include a loc->loc rule; it only would do that if the DEST column contained ''all+''. Now the first rule appears to be superfluous because the loc->fw policy is ACCEPT. So with OPTIMIZE=1, the rule is omitted from the ruleset. This only happens with wildcard rules (those containing some form of ''all'' in either SOURCE or DEST). If the rules file would have contained the first rule explicitly, it would not have been omitted. As I mentioned in the previous email, if the ACTION is followed by "!", no wildcard optimization occurs. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/