On Mon, Sep 21, 2020 at 7:54 PM Gregory P. Ennis wrote:
>
> Everyone,
>
> I would like to use our gateway linux machine to give bandwidth preference to
> voip udp
> packets. Can anyone point me to a tutorial about the use of voip and
> iptables?
Arch Linux wiki has nice explanations and exampl
--On Friday, July 17, 2020 6:43 AM +0530 Kaushal Shriyan
wrote:
Please refer to my pastebin link https://paste.centos.org/view/cd55a9a6.
Basically I want to allow the below mentioned ruleset on the server
(CentOS Linux release 8.2.2004 (Core)) and drop the rest of the network
traffic from 0.0.
On Fri, Jul 17, 2020 at 2:41 AM Kenneth Porter
wrote:
> --On Thursday, July 16, 2020 10:41 PM +0530 Kaushal Shriyan
> wrote:
>
> > I have run the below command but I am still able to connect from the
> > internet. Do I need to add any drop traffic policy using nft?
>
> A single rule doesn't tell
--On Thursday, July 16, 2020 10:41 PM +0530 Kaushal Shriyan
wrote:
I have run the below command but I am still able to connect from the
internet. Do I need to add any drop traffic policy using nft?
A single rule doesn't tell us enough. Dump the entire firewall to a
pastebin and post the lin
Am 16.07.20 um 18:11 schrieb Kaushal Shriyan:
On Thu, Jul 16, 2020 at 9:25 PM Phil Perry wrote:
On 16/07/2020 16:48, Kaushal Shriyan wrote:
Hi,
I am running CentOS Linux release 8.2.2004 (Core) on a remote server. I
am
running the below iptables command to allow SSH port 22 from a specific
the issue by other means, it may be necessary.
From: CentOS on behalf of Phil Perry
Sent: Thursday, July 16, 2020 10:54 AM
To: centos@centos.org
Subject: [EXTERNAL] Re: [CentOS] Iptables rules not working
CAUTION: This email originated from outside of the organi
On Thu, Jul 16, 2020 at 9:25 PM Phil Perry wrote:
> On 16/07/2020 16:48, Kaushal Shriyan wrote:
> > Hi,
> >
> > I am running CentOS Linux release 8.2.2004 (Core) on a remote server. I
> am
> > running the below iptables command to allow SSH port 22 from a specific
> > source IP 219.91.200.59
> >
On 16/07/2020 16:48, Kaushal Shriyan wrote:
Hi,
I am running CentOS Linux release 8.2.2004 (Core) on a remote server. I am
running the below iptables command to allow SSH port 22 from a specific
source IP 219.91.200.59
iptables -A INPUT -m tcp -p tcp -s 219.91.200.59 --dport 22 -j ACCEPT
servi
Am 16.07.2020 um 17:48 schrieb Kaushal Shriyan:
Hi,
I am running CentOS Linux release 8.2.2004 (Core) on a remote server. I am
running the below iptables command to allow SSH port 22 from a specific
source IP 219.91.200.59
iptables -A INPUT -m tcp -p tcp -s 219.91.200.59 --dport 22 -j ACCEPT
s
On 6/26/2019 2:41 AM, MRob wrote:
> I am working to a CentOS 6 server with nonstandard iptables system without
> rule for
> ACCEPT ESTABLISHED connections. All tables and chains empty (flush by legacy
> custom
> script) so only filter/INPUT chain has rules (also fail2ban chain):
>
> Chain INPUT (
On 6/25/19 11:41 PM, MRob wrote:
When fail2ban block a IP address, established connections are allowed
to continue, but with no rule to accept established connections how is
that possible?
It doesn't look like it would be.
1: Open a connection that will demonstrate the problem later.
2: Trig
On 6/26/19 8:41 AM, MRob wrote:
I am working to a CentOS 6 server with nonstandard iptables system without rule
for ACCEPT ESTABLISHED connections. All tables and chains empty (flush by
legacy custom script) so only filter/INPUT chain has rules (also fail2ban
chain):
Chain INPUT (policy ACCEP
On 2019-06-26 02:41, MRob wrote:
I am working to a CentOS 6 server with nonstandard iptables system
without rule for ACCEPT ESTABLISHED connections. All tables and chains
empty (flush by legacy custom script) so only filter/INPUT chain has
rules (also fail2ban chain):
Chain INPUT (policy ACCEPT)
Yes, I have double checked and am sure there is no IP address conflicts.
Likun
On 4/24/19 23:28, centos wrote:
>On 4/24/19 10:31, likun wrote:
>> Hello, Stephen, thank you for input.
>>
>> Yes, these servers have the same firewall rules, and both of them have
the same problem from time to time,
Yes, I have double checked and am sure there is no IP address conflicts.
Likun
On 4/24/19 23:28, centos wrote:
>On 4/24/19 10:31, likun wrote:
>> Hello, Stephen, thank you for input.
>>
>> Yes, these servers have the same firewall rules, and both of them have
the same problem from time to time,
On Wed, 24 Apr 2019 at 06:01, likun wrote:
> Hi，guys.
>
> There is a wierd problem with iptables recently, hopes somebody can help
> me.
>
> I have installed Centos 7.2.1511 on a bare metal Dell server these days,
> disabled firewalld and enabled iptables.services, and setup a group of very
> sim
On Fri, Feb 16, 2018 at 02:54:02PM +, Ken Gramm wrote:
> I've been searching around for a couple of days, and I just can't
> seem to find the answer I'm looking for.
>
>
> I have a 6.x box that I use as my gateway firewall. It has three
> NICs; 1 external, 1 internal, 1 for a guest network.
On 10/16/2016 05:39 PM, Jerry Geis wrote:
I am running asterisk (11.23.0) on a C5 machine. Working fine on port 5060
udp. I have need to tcpenable=yes SIP and run that on port 5068.
Since port 5060 is already running I was going to redirect 5068 to 5060.
Oh, yuck. SIP includes information abou
On Tue, 13 Sep 2016, TE Dukes wrote:
-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of John R Pierce
Sent: Sunday, September 11, 2016 10:44 PM
To: centos@centos.org
Subject: Re: [CentOS] Iptables not save rules
On 9/11/2016 8:55 AM
On Tue, Sep 13, 2016 at 08:16:28AM -0400, TE Dukes wrote:
>
>
> > -Original Message-
> > From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
> > Behalf Of John R Pierce
> > Sent: Sunday, September 11, 2016 10:44 PM
> > To: centos
> -Original Message-
> From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
> Behalf Of John R Pierce
> Sent: Sunday, September 11, 2016 10:44 PM
> To: centos@centos.org
> Subject: Re: [CentOS] Iptables not save rules
>
> On 9/11/2016 8:55 AM, TE
On 9/11/2016 8:55 AM, TE Dukes wrote:
I have been using ipset to blacklist badbots. Works like a champ!
The only problem is if I do a system reboot, I lose the ipset and the rule.
I changed /etc/sysconfig/iptables.conf to:
IPTABLES_SAVE_ON_RESTART="yes"
IPTABLES_SAVE_ON_STOP="yes"
And follow
On Thu, 2016-02-25 at 07:19 +, James Hogarth wrote:
> Well if you really want to call it a problem... Blocking ICMP via a host
> based firewall remains pretty silly.
On all servers I used IPtables to block (DROP) all incoming ICMPs
except:-
type 0 state RELATED,ESTABLISHED
type 3 state REL
On 25 Feb 2016 00:30, "John Cenile" wrote:
>
> Thanks all, that seemed to be the problem (the suid bit). :)
Well if you really want to call it a problem... Blocking ICMP via a host
based firewall remains pretty silly.
Bear in mind that since it's a file permission this will be 'fixed' on any
upd
Thanks all, that seemed to be the problem (the suid bit). :)
On 25 February 2016 at 06:03, Valeri Galtsev
wrote:
> On Wed, February 24, 2016 12:25 pm, Alexander Dalloz wrote:
> > Am 24.02.2016 um 16:07 schrieb Sylvain CANOINE:
> >> Hello,
> >> - Mail original -
> >>> De: "John Cenile"
>
On Wed, February 24, 2016 12:25 pm, Alexander Dalloz wrote:
> Am 24.02.2016 um 16:07 schrieb Sylvain CANOINE:
>> Hello,
>> - Mail original -
>>> De: "John Cenile"
>>> Ã: "centos"
>>> Envoyé: Mercredi 24 Février 2016 15:42:36
>>> Objet: [CentOS] IPtables block user from outbound ICMP
>>
Am 24.02.2016 um 15:42 schrieb John Cenile:
Hello,
Is it possible at all to block all users other than root from sending
outbound ICMP packets on an interface?
At the moment we have the following two rules in our IPtables config:
iptables -A OUTPUT -o eth1 -m owner --uid-owner 0 -j ACCEPT
ipta
Am 24.02.2016 um 16:07 schrieb Sylvain CANOINE:
Hello,
- Mail original -
De: "John Cenile"
À: "centos"
Envoyé: Mercredi 24 Février 2016 15:42:36
Objet: [CentOS] IPtables block user from outbound ICMP
Is it possible at all to block all users other than root from sending
outbound ICM
On 02/24/2016 06:42 AM, John Cenile wrote:
Is it possible at all to block all users other than root from sending
outbound ICMP packets on an interface?
That is, more or less, the default. In order to send ICMP packets, an
application must be root, or must have the CAP_NET_RAW capability (as
Hello,
- Mail original -
> De: "John Cenile"
> À: "centos"
> Envoyé: Mercredi 24 Février 2016 15:42:36
> Objet: [CentOS] IPtables block user from outbound ICMP
> Is it possible at all to block all users other than root from sending
> outbound ICMP packets on an interface?
>
> At the mo
James B. Byrne writes:
>
> Would someone please explain to me the difference in effect between
> the following two IPTABLES conditions and the significance thereof in
> concurrent connection limiting?
>
> --tcp-flags SYN,ACK,FIN,RST SYN -j REJECT \
> --connlimit-above 3 --connlimit-mask 32
>
On Thu, 2015-04-02 at 22:42 -0600, Paul R. Ganci wrote:
> I had turned off firewalld and was using iptables when I originally
> installed CentOS 7.0. Two days ago I upgraded my CentOS 7.0 to 7.1.
> Everything seemed to be fine. Today I discovered that my iptables
> configuration was removed wit
No there was nothing. Having said that I think I was having a "senior moment."
I have two servers on which I am testing 7.x. These are isolated machines that
if I had to I could just wipe and start over. On one machine the
/etc/sysconfig/iptables was intact after the upgrade. On the other it wa
On Thu, 02 Apr 2015 22:42:02 -0600
Paul R. Ganci wrote:
> Literally the /etc/sysconfig/iptables is gone and
> the /etc/sysconfig/iptables-config is the blank template that comes with
> the distribution. This seems to me to be a serious bug with the upgrade.
Do you have a .rpmsave file in that d
+1
On Tue, Jun 17, 2014 at 9:41 AM, James B. Byrne
wrote:
>
> On Mon, June 16, 2014 23:34, Chuck Campbell wrote:
>
> > I appreciate you restating this. I'll try to go make sense of iptables,
> given
> > the insight,
> >
>
> Keep in mind that there are three default chains, INPUT, OUTPUT and F
On 6/17/2014 19:35, Chuck Campbell wrote:
> I haven't done the load stats, but it appears
> to me that a hundred of these crackers hitting my machine at these rates is
> likely to deny my legit users some resources.
So increase the fail2ban time from the default (5 minutes, as I recall)
to 1 hour
On 6/17/2014 6:39 PM, Warren Young wrote:
> On 6/16/2014 15:58, Chuck Campbell wrote:
>> If they keep going through this ip block, they will still get 255 attempts at
>> the root password and 1020 attempts at other login/password combinations
>> before
>> they are blocked by fail2ban.
> I'm glad y
On 6/16/2014 15:58, Chuck Campbell wrote:
> If they keep going through this ip block, they will still get 255 attempts at
> the root password and 1020 attempts at other login/password combinations
> before
> they are blocked by fail2ban.
I'm glad you got your firewall problem sorted out, but I ca
On 6/17/2014 2:14 PM, Chuck Campbell wrote:
> I'll experiment with that when I am physically in front of the
> server, instead of remote from it. I would have had no quick remedy if I
> messed
> it up.
thats why all my servers have remote consoles :)
--
john r pierce
On 6/16/2014 11:08 PM, John R Pierce wrote:
> On 6/16/2014 8:52 PM, Chuck Campbell wrote:
>> I ran a script after fail2ban was started. It looks like this:
>> #!/bin/sh
>> iptables -A INPUT -s 116.10.191.0/24 -j DROP
>> iptables -A INPUT -s 183.136.220.0/24 -j DROP
>> iptables -A INPUT -s 183.136.2
On 06/17/2014 10:41 AM, James B. Byrne wrote:
> On Mon, June 16, 2014 23:34, Chuck Campbell wrote:
>
>> I appreciate you restating this. I'll try to go make sense of iptables, given
>> the insight,
>>
> Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD
> that are used to i
On Mon, June 16, 2014 23:34, Chuck Campbell wrote:
> I appreciate you restating this. I'll try to go make sense of iptables, given
> the insight,
>
Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD
that are used to initiate the packet path through IPTABLES and that they
On 6/16/2014 8:52 PM, Chuck Campbell wrote:
> I ran a script after fail2ban was started. It looks like this:
> #!/bin/sh
> iptables -A INPUT -s 116.10.191.0/24 -j DROP
> iptables -A INPUT -s 183.136.220.0/24 -j DROP
> iptables -A INPUT -s 183.136.221.0/24 -j DROP
> iptables -A INPUT -s 183.136.222.
>>>
>>>
>> As John R Pierce mentioned one of your first rule in the chain is
>> "RH-Firewall-1-INPUT all -- anywhere anywhere", this
>> simply mean everything with "DROP" after it will be ignored. iptables
>> will work its way down the chain, therefore you have to options
>> 1. remo
On 6/16/2014 9:44 PM, Earl Ramirez wrote:
> On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
>> All of the suggestions are graciously accepted, however, I was actually
>> asking
>> what I was doing wrong with iptables, and why, with the rules I put in place,
>> someone was still able to co
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
> All of the suggestions are graciously accepted, however, I was actually
> asking
> what I was doing wrong with iptables, and why, with the rules I put in place,
> someone was still able to connect to my machine.
>
> I understand there m
All of the suggestions are graciously accepted, however, I was actually asking
what I was doing wrong with iptables, and why, with the rules I put in place,
someone was still able to connect to my machine.
I understand there might be better ways, but if I don't understand what I did
wrong last
[previous article hasn't appeared on gmane yet]
On 2014-06-16, Eliezer Croitoru wrote:
> On 06/17/2014 01:46 AM, Bret Taylor wrote:
>> Get rid of fail2ban, it's not needed. Just write a proper firewall.
> Are you series??
> There are applications that fail2ban offers them things which others
> j
On 06/17/2014 01:46 AM, Bret Taylor wrote:
> Get rid of fail2ban, it's not needed. Just write a proper firewall.
Are you series??
There are applications that fail2ban offers them things which others
just can't..
If you can email me the ip for your servers and also the root password
and allow me
On 06/17/2014 01:11 AM, John R Pierce wrote:
> On 6/16/2014 2:58 PM, Chuck Campbell wrote:
>> >Chain INPUT (policy ACCEPT)
>> >target prot opt source destination
>> >fail2ban-VSFTPD tcp -- anywhere anywheretcp
>> >dpt:ftp
>> >fail2ban-SSH tcp -- anyw
On 6/16/2014 2:58 PM, Chuck Campbell wrote:
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> fail2ban-VSFTPD tcp -- anywhere anywheretcp dpt:ftp
> fail2ban-SSH tcp -- anywhere anywheretcp dpt:ssh
> RH-Firewa
On Mon, 16 Jun 2014 16:58:18 -0500
Chuck Campbell wrote:
> Why is this ip range still able to attempt connections? Have I done something
> wrong with my address ranges, or added them in the wrong place?
Have you considered taking the opposite approach and allowing only the IP
addresses that you
On Mon, 2014-06-16 at 16:58 -0500, Chuck Campbell wrote:
> I'm running fail2ban to attempt to block malicious brute-force password
> dictionary attacks against ssh.
You could:-
(1) Change the SSHD port to something obscure.
(2) Restrict access to the SSHD port, using iptables, to a group of
ap
On Tue, Nov 5, 2013 at 5:22 PM, John R Pierce wrote:
> On 11/5/2013 3:55 PM, Wes James wrote:
> > I ran:
> >
> > iptables -L
>
> incomplete output. try...
>
> iptables -L -vn
>
> and you'll probably see that reject is for a specific packet type. the v
> is for verbose, the n is for numeric outpu
On 11/5/2013 3:55 PM, Wes James wrote:
> I ran:
>
> iptables -L
incomplete output. try...
iptables -L -vn
and you'll probably see that reject is for a specific packet type. the v
is for verbose, the n is for numeric output (no DNS lookup)
--
john r pierce
On Sat, Mar 30, 2013 at 12:54 PM, SilverTip257 wrote:
> On Fri, Mar 29, 2013 at 1:09 PM, zGreenfelder >wrote:
>
> > On Fri, Mar 29, 2013 at 12:37 PM, Pat Haley wrote:
> > >
> > > Hi,
> > >
> > > Actually we're talking about both SSH and XDMCP X11 forwarding.
> > > Both seem to be currently disab
On Fri, Mar 29, 2013 at 1:09 PM, zGreenfelder wrote:
> On Fri, Mar 29, 2013 at 12:37 PM, Pat Haley wrote:
> >
> > Hi,
> >
> > Actually we're talking about both SSH and XDMCP X11 forwarding.
> > Both seem to be currently disabled by the iptables.
> >
> > We'll try out what you suggest and get back
On Fri, Mar 29, 2013 at 12:37 PM, Pat Haley wrote:
>
> Hi,
>
> Actually we're talking about both SSH and XDMCP X11 forwarding.
> Both seem to be currently disabled by the iptables.
>
> We'll try out what you suggest and get back with the results.
> Thanks.
>
> Pat
iptables should have no effect (
Hi,
Actually we're talking about both SSH and XDMCP X11 forwarding.
Both seem to be currently disabled by the iptables.
We'll try out what you suggest and get back with the results.
Thanks.
Pat
> On Fri, Mar 29, 2013 at 11:34 AM, Pat Haley wrote:
>
>> Hi,
>>
>> We recently installed CentOS
On Fri, Mar 29, 2013 at 11:34 AM, Pat Haley wrote:
>
> Hi,
>
> We recently installed CentOS 6.2 on our cluster. During
> the installation/debugging of various secondary software, we had
> disabled iptables. When we re-enabled them, we found that the
> front-end would no longer X11 forward (alth
From: Earl A Ramirez
To: CentOS mailing list
Sent: Tuesday, December 4, 2012 3:25 PM
Subject: Re: [CentOS] iptables port forwarding
On 5 December 2012 03:38, Joseph Spenner wrote:
> I have a simple requirement/test I'm trying to perform, bu
On 5 December 2012 03:38, Joseph Spenner wrote:
> I have a simple requirement/test I'm trying to perform, but having
> difficulty.
>
> I have a system with 2 interfaces, BoxA:
>
> eth0 172.26.50.102
> eth1 192.101.77.62
>
> My goal is to have a tcp port built on BoxA such that hosts on the
> 19
=?ISO-8859-1?Q?Miguel_Gonz=E1lez_Casta=F1os?= wrote on Tue, 04 Dec 2012
02:09:26 +0100:
> How can I enable that CONFIG_IP_NF_MATCH_STATE support in my kernel?
Sounds like your are not running the standard kernel, but something
provided by your VPS provider. If that is indeed the case you have t
On Fri, 2012-11-09 at 18:10 +0100, Dennis Jacobfeuerborn wrote:
> On 11/09/2012 02:07 PM, Helmut Drodofsky wrote:
> > Helo,
> >
> > we use recent to control ip traffic.
> > kernel 2.6.18-308.13.1.el5 : all is OK
> > kernel 2.6.18-308.16.1.el5 : the first recent statement causes an error.
> > E.g.:
On 11/09/2012 02:07 PM, Helmut Drodofsky wrote:
> Helo,
>
> we use recent to control ip traffic.
> kernel 2.6.18-308.13.1.el5 : all is OK
> kernel 2.6.18-308.16.1.el5 : the first recent statement causes an error.
> E.g.:
> iptables -A INPUT -m state --state NEW -m recent --set -p tcp --dport 80
>
On 08/02/2012 01:06 PM, Blackburn, Marvin wrote:
> I have a server that allows incoming traffic for ssh and some other
> things.
>
> I need to set up a rule that will drop/reject all traffic from a
> particular server except ssh.
>
> How can I do that.
>
>
>
>
>
>
Hello Helmut,
On Mon, 2012-06-11 at 11:54 +0200, Helmut Drodofsky wrote:
> up to CentOS 5.3 it was possible, to control new ip connections by
> "recent", "seconds" and "hitcount"
>
> -A INPUT -m state --state NEW -m recent --set -p tcp --dport 80
> -A INPUT -m state --state NEW -m recent --updat
On Friday 27 April 2012 18:41, the following was written:
> On 4/27/2012 5:05 PM, Bob Hoffman wrote:
> > dropping IPs by host machine, protecting the vms.
> > would something like this work
> >
> > -A PREROUTING -s 66.77.65.128/26 -j DROP
> >
> >
> > or would my server die upon testing it.
On 4/27/2012 5:05 PM, Bob Hoffman wrote:
> dropping IPs by host machine, protecting the vms.
> would something like this work
>
> -A PREROUTING -s 66.77.65.128/26 -j DROP
>
>
> or would my server die upon testing it...lol
> ___
>
okay, after about 400 ate
On 4/27/2012 9:36 AM, Bob Hoffman wrote:
> Does this work?
>
> adding DROP to iptables on the virtual host's iptables, before the phys
> bridgewill it prevent those ips from getting to the bridged part of
> iptables? Or would a different syntax be used?
>
>
> -A INPUT -s 66.77.65.128/26 -j DROP
On 02/14/2012 01:28 PM, Robert Spangler wrote:
> On Tuesday 14 February 2012 15:21, the following was written:
>
>> Is there a way to add a rule to the nat table (CentOS 5.7) that would
>> alter the port number of tcp packets destined for the server itself? I
>> have ip_forwarding enabled, but
On Tuesday 14 February 2012 15:21, the following was written:
> Is there a way to add a rule to the nat table (CentOS 5.7) that would
> alter the port number of tcp packets destined for the server itself? I
> have ip_forwarding enabled, but the packets don't seem to hit the
> prerouting chain
On 08/01/2011 03:23 PM, Kenneth Porter wrote:
--On Wednesday, July 20, 2011 10:44 AM -0500 cbul...@gmail.com wrote:
We are trying to track some specific rules using LOG as target.
Everything is working well but the problem is that iptables is flooding
the console with LOG messages.
In additio
--On Wednesday, July 20, 2011 10:44 AM -0500 cbul...@gmail.com wrote:
> We are trying to track some specific rules using LOG as target.
> Everything is working well but the problem is that iptables is flooding
> the console with LOG messages.
In addition to the other suggestions, you could switc
On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
*snip*
> Keith and Daniel,
>
> Thanks so much for your help!.
>
> Keith you are right. I had --log-level 4 in the iptables
> rules because I played with that option in order to fix
> the problem. Now, it's working well. I didn't update the
> kernel
On 7/20/2011 12:52 PM, Keith Roberts wrote:
> On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
>
>> To: centos@centos.org
>> From: "cbul...@gmail.com"
>> Subject: Re: [CentOS] Iptables - flooding console
>>
>>
>>
>> On 7/20/2011 10
On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
> To: centos@centos.org
> From: "cbul...@gmail.com"
> Subject: Re: [CentOS] Iptables - flooding console
>
>
>
> On 7/20/2011 10:18 AM, Keith Roberts wrote:
>> On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
>>
On Wed, Jul 20, 2011 at 9:40 AM, cbul...@gmail.com wrote:
>
>
> On 7/20/2011 10:18 AM, Keith Roberts wrote:
> > On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
> >
> >> To: centos@centos.org
> >> From: "cbul...@gmail.com"
> >> Subject: [CentOS] Iptables - flooding console
> >>
> >> Hi,
> >>
> >> We
On 7/20/2011 10:18 AM, Keith Roberts wrote:
> On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
>
>> To: centos@centos.org
>> From: "cbul...@gmail.com"
>> Subject: [CentOS] Iptables - flooding console
>>
>> Hi,
>>
>> We are trying to track some specific rules using LOG as target.
>> Everything is wo
On Wed, 20 Jul 2011, cbul...@gmail.com wrote:
> To: centos@centos.org
> From: "cbul...@gmail.com"
> Subject: [CentOS] Iptables - flooding console
>
> Hi,
>
> We are trying to track some specific rules using LOG as target.
> Everything is working well but the problem is that iptables is flooding
Thanks all!
I'm studying iptables at the moment, Hope I can help others in the feture :)
At 2011-06-28，"Ljubomir Ljubojevic" wrote:
>Christopher Chan wrote:
>> Er, you are not making much sense here. John posts that -v is needed to
>> not get the 'digested result' but the 'full result'
On Tuesday, June 28, 2011 05:22 PM, Ljubomir Ljubojevic wrote:
Christopher Chan wrote:
Er, you are not making much sense here. John posts that -v is needed
to not get the 'digested result' but the 'full result' and then you go
off on a branch about iptables-save. Oh, I still don't see what
diffe
Christopher Chan wrote:
Er, you are not making much sense here. John posts that -v is needed to
not get the 'digested result' but the 'full result' and then you go off
on a branch about iptables-save. Oh, I still don't see what difference
there is between iptables -nv -L ${table} and iptables-s
On Tuesday, June 28, 2011 04:05 PM, Ljubomir Ljubojevic wrote:
Christopher Chan wrote:
On Tuesday, June 28, 2011 02:38 AM, Ljubomir Ljubojevic wrote:
John R Pierce wrote:
On 06/27/11 10:43 AM, Ljubomir Ljubojevic wrote:
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`,
Christopher Chan wrote:
On Tuesday, June 28, 2011 02:38 AM, Ljubomir Ljubojevic wrote:
John R Pierce wrote:
On 06/27/11 10:43 AM, Ljubomir Ljubojevic wrote:
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need
`iptabl
On Tuesday, June 28, 2011 02:38 AM, Ljubomir Ljubojevic wrote:
John R Pierce wrote:
On 06/27/11 10:43 AM, Ljubomir Ljubojevic wrote:
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need
`iptable -L -vn -t nat` to see t
John R Pierce wrote:
On 06/27/11 10:43 AM, Ljubomir Ljubojevic wrote:
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need
`iptable -L -vn -t nat` to see those chains, and `iptable -L -vn -t
mangle` if you're using an
On 06/27/11 10:43 AM, Ljubomir Ljubojevic wrote:
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need
`iptable -L -vn -t nat` to see those chains, and `iptable -L -vn -t
mangle` if you're using any mangle entries.
ip
John R Pierce wrote:
On 06/27/11 12:05 AM, muiz wrote:
[root@localhost ~]# /sbin/iptables -L
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need `iptable
-L -vn -t nat` to see those chains, and `iptable -L -vn -t m
Dear all,
Thanks very much for your kindly help! I use below codes to update the
firewall, and it works now.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -d 192.168.1.250 -p tcp -m tcp --dport 8080 -j
DNAT --to-destination a.b.c.d:8181
iptables -t nat -A POSTROUTING
On 06/27/11 12:05 AM, muiz wrote:
[root@localhost ~]# /sbin/iptables -L
note that doesn't show all the pertinent info. I prefer `iptable -L
-vn`, and it still doesn't show the nat tables, you also need `iptable
-L -vn -t nat` to see those chains, and `iptable -L -vn -t mangle` if
you're usin
On Monday, June 27, 2011 03:15 PM, Ljubomir Ljubojevic wrote:
muiz wrote:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Culprit right here. You need to allow connections to a.b.c.d.
Chain OUTPUT (policy AC
muiz wrote:
Dear all,
Below is my iptables default settings: (only open port 22 and 8080
(webcache))
-
[root@localhost ~]# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target pr
Dear all,
Below is my iptables default settings: (only open port 22 and 8080
(webcache))
-
[root@localhost ~]# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source
Marian Marinov wrote:
> On Monday 27 June 2011 07:15:33 muiz wrote:
>> Marian, I'm very happy you're online :)I think I have try the record you
>> mention just now. And I would like to clear what I have done (the scripts
>> I test):/sbin/iptables -t nat -A PREROUTING -j DNAT -p tcp --dport 8080
>>
On Monday 27 June 2011 07:15:33 muiz wrote:
> Marian, I'm very happy you're online :)I think I have try the record you
> mention just now. And I would like to clear what I have done (the scripts
> I test):/sbin/iptables -t nat -A PREROUTING -j DNAT -p tcp --dport 8080
> --to a.b.c.d:8181 /sbin/ipt
Marian, I'm very happy you're online :)I think I have try the record you
mention just now. And I would like to clear what I have done (the scripts I
test):/sbin/iptables -t nat -A PREROUTING -j DNAT -p tcp --dport 8080 --to
a.b.c.d:8181
/sbin/iptables -t nat -A POSTROUTING -j SNAT -s 192.168.0
On Monday 27 June 2011 06:50:27 muiz wrote:
> Dear Marian and all,
> It seems don't works:
> /sbin/iptables -t nat -A PREROUTING -j DNAT -p tcp --dport 8080 --to
> a.b.c.d:8181 /sbin/iptables -t nat -A POSTROUTING -j SNAT -s
> 192.168.0.0/255.255.255.0 --to a.b.c.d echo 1 >
> /proc/sys/net/ipv4/i
Dear Marian and all,
It seems don't works:
/sbin/iptables -t nat -A PREROUTING -j DNAT -p tcp --dport 8080 --to
a.b.c.d:8181
/sbin/iptables -t nat -A POSTROUTING -j SNAT -s 192.168.0.0/255.255.255.0 --to
a.b.c.d
echo 1 > /proc/sys/net/ipv4/ip_foward
I check the Fedora iptables setting: /etc/
On Monday 27 June 2011 00:08:08 muiz wrote:
> Thanks Marian,
> The server only has one IP. I think I should add more iptables records,
> only one NAT record is not enough,isit correct? If yes , then how?
Huh, I'm sorry yes you need a second rule. So the rules are:
iptables -t nat -A PREROUTING -
1 - 100 of 366 matches
Mail list logo
