W dniu 14.09.2018 o 10:25, Deventer-2, M.S.J. van pisze:
> this has nothing to do with CentOS but with your router which does not
> support using the public IP from inside your network (which is quite
> common).
> If the port is open on your router when you access it from another
> public IP then
Hi,
this has nothing to do with CentOS but with your router which does not
support using the public IP from inside your network (which is quite
common).
If the port is open on your router when you access it from another
public IP then all is well.
Regards,
Michel
On Fri, 2018-09-14 at 09:43
W dniu 13.09.2018 o 22:19, Oleg Cherkasov pisze:
> On 13. sep. 2018 21:02, Marcin Trendota wrote:
>>
>> There is nginx on port 80.
>> I've turned off SELinux for testing purposes.
>>
>> [root@chamber ~]# nmap chamber -p80
>> [...]
>> PORT STATE SERVICE
>> 80/tcp open http
>>
>> [root@chamber ~]#
On 13. sep. 2018 21:02, Marcin Trendota wrote:
There is nginx on port 80.
I've turned off SELinux for testing purposes.
[root@chamber ~]# nmap chamber -p80
[...]
PORT STATE SERVICE
80/tcp open http
[root@chamber ~]# nmap -p80 chmura.
[...]
PORT STATE SERVICE
80/tcp closed http
Do a qui
Hello all
I have weird problem i can't understand and don't know where to look.
[root@chamber ~]# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever pre
On 10/10/2012 04:32 AM, Steve Clark wrote:
> Thanks for the response. We have 450 units in the field and have only needed
> to do this at one site. I am
> using a userspace script to monitor the viability of each isp and changing
> the routing accordingly as
> described in the LARTC document. Our
On Wed, Oct 10, 2012 at 6:32 AM, Steve Clark wrote:
>
I was trying to figure out what criteria to use to mark the connection.
FTP is such a
braindead application, using to channels and active and passive mode.
What really
needs to happen is someway to tell the kernel to re
On 10/09/2012 05:36 PM, Ljubomir Ljubojevic wrote:
> On 09/27/2012 05:24 PM, Gordon Messmer wrote:
>> On 09/27/2012 06:36 AM, Steve Clark wrote:
>>> I was trying to figure out what criteria to use to mark the connection.
>>> FTP is such a
>>> braindead application, using to channels and active and
On 09/27/2012 05:24 PM, Gordon Messmer wrote:
> On 09/27/2012 06:36 AM, Steve Clark wrote:
>> I was trying to figure out what criteria to use to mark the connection.
>> FTP is such a
>> braindead application, using to channels and active and passive mode.
>> What really
>> needs to happen is somewa
On Wed, Oct 3, 2012 at 7:00 PM, Steve Clark wrote:
> On 10/03/2012 08:46 AM, Manish Kathuria wrote:
>
> I was under the impression that you are running a FTP server inside
> and were facing problems with the incoming traffic for the same. If
> you are primarily concerned with the outgoing traffic
On 10/03/2012 08:46 AM, Manish Kathuria wrote:
>>
> I was under the impression that you are running a FTP server inside
> and were facing problems with the incoming traffic for the same. If
> you are primarily concerned with the outgoing traffic through two ISP
> links, please follow the following
Sounds like an issue similar to what I experienced when trying to force
all outgoing ssh traffic on a NAT'ed network to go through a particular
interface. I've forgot the details, but running the following on the
firewall helped
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 0 > $f
>
> The routes-x.y-z.diff is a unified patch containing different parts
> which include support for Dead Gateway Detection as well. However,
> since that is limited to the first hop, it is preferable to have a
> userspace script as you are doing. I also use a script to check the
> accessibility of
On 09/27/2012 09:47 PM, Manish Kathuria wrote:
> On Thu, Sep 27, 2012 at 8:55 PM, Steve Clark wrote:
>> On 09/27/2012 11:01 AM, Manish Kathuria wrote:
>>
>> On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark wrote:
>>
>> On 09/26/2012 11:57 PM, Manish Kathuria wrote:
>>
>> On Thu, Sep 27, 2012 at 7:46
On Thu, Sep 27, 2012 at 8:55 PM, Steve Clark wrote:
> On 09/27/2012 11:01 AM, Manish Kathuria wrote:
>
> On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark wrote:
>
> On 09/26/2012 11:57 PM, Manish Kathuria wrote:
>
> On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer wrote:
>
> On 09/26/2012 09:15 AM, S
On 09/27/2012 11:01 AM, Manish Kathuria wrote:
> On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark wrote:
>> On 09/26/2012 11:57 PM, Manish Kathuria wrote:
>>
>> On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer wrote:
>>
>> On 09/26/2012 09:15 AM, Steve Clark wrote:
> The routes-x.y-z.diff is a unified
On 09/27/2012 06:36 AM, Steve Clark wrote:
> I was trying to figure out what criteria to use to mark the connection.
> FTP is such a
> braindead application, using to channels and active and passive mode.
> What really
> needs to happen is someway to tell the kernel to recheck the routing
> after S
On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark wrote:
> On 09/26/2012 11:57 PM, Manish Kathuria wrote:
>
> On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer wrote:
>
> On 09/26/2012 09:15 AM, Steve Clark wrote:
>
> Is there a way to make this work correctly?
>
> In addition, you should ideally apply
On 09/26/2012 10:16 PM, Gordon Messmer wrote:
> On 09/26/2012 09:15 AM, Steve Clark wrote:
>> Is there a way to make this work correctly?
> Shorewall will generate a proper configuration if you specify the
> "track" option in the "providers" file. It might be a good idea to use
> that to generate
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
> On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer wrote:
>> On 09/26/2012 09:15 AM, Steve Clark wrote:
>>> Is there a way to make this work correctly?
> In addition, you should ideally applying the following patches for
> Static, Alternative Routes,
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer wrote:
> On 09/26/2012 09:15 AM, Steve Clark wrote:
>> Is there a way to make this work correctly?
>
> Shorewall will generate a proper configuration if you specify the
> "track" option in the "providers" file. It might be a good idea to use
> that
On 09/26/2012 09:15 AM, Steve Clark wrote:
> Is there a way to make this work correctly?
Shorewall will generate a proper configuration if you specify the
"track" option in the "providers" file. It might be a good idea to use
that to generate your configs rather than building them by hand.
I b
Hello,
This is on Centos 6 and not something I think is wrong with Centos 6
but I am looking to see if anybody else has experienced this and
if there is solution. So thanks up front for indulging me.
Because Linux makes routing decisions before SNAT it is causing
problems when trying to use FTP w
Les Mikesell escribió:
On 12/19/10 1:45 PM, Jose Maria Terry Jimenez wrote:
I wanted the reverse path. Traceroute from the 192.168.236.80 box back to the
fedora address. It doesn't make sense that it can return packets without a
route going through the Centos box.
Hello
This arrive
Andrej Moravcik escribió:
Hello Jose,
from the picture you provided the situation looks pretty simple.
- you have enabled IP forwarding on router, I recommend you to put it
into /etc/sysctl.conf for persistence.
- you have configured firewall rules on router to allow forwarding
traffic from
Hello Jose,
from the picture you provided the situation looks pretty simple.
- you have enabled IP forwarding on router, I recommend you to put it
into /etc/sysctl.conf for persistence.
- you have configured firewall rules on router to allow forwarding
traffic from left to right subnet. You ca
El 19/12/2010, a las 23:15, Les Mikesell escribió:
> On 12/19/10 4:08 PM, José María Terry Jiménez wrote:
>> Les Mikesell escribió:
>>> On 12/19/10 2:30 PM, Jose Maria Terry Jimenez wrote:
>>>
This doesn't make much sense without a route. Can you try a
traceroute to the
On 12/19/10 4:08 PM, José María Terry Jiménez wrote:
> Les Mikesell escribió:
>> On 12/19/10 2:30 PM, Jose Maria Terry Jimenez wrote:
>>
>>> This doesn't make much sense without a route. Can you try a traceroute
>>> to the
>>> fedora box address from the 192.168.236.80 box to see how/
Les Mikesell escribió:
On 12/19/10 2:30 PM, Jose Maria Terry Jimenez wrote:
This doesn't make much sense without a route. Can you try a traceroute to the
fedora box address from the 192.168.236.80 box to see how/why it gets there
Hope it helps (all addresses are 192.168. Trimmed to compac
On 12/19/10 2:30 PM, Jose Maria Terry Jimenez wrote:
>
>
> This doesn't make much sense without a route. Can you try a traceroute
> to the
> fedora box address from the 192.168.236.80 box to see how/why it gets
> there?
>>
> Hope it helps (all addresses are 192.168. Tri
El 19/12/10 21:17, Michel van Deventer escribió:
> Hi,
>
> The Fedora box (1. network):
> [j...@idi ~]$ ping 192.168.236.80
> PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data.
> 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=1.61 ms
> 64 bytes from 192.168.236.80:
Hi,
> >>> The Fedora box (1. network):
> >>> [j...@idi ~]$ ping 192.168.236.80
> >>> PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data.
> >>> 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=1.61 ms
> >>> 64 bytes from 192.168.236.80: icmp_req=2 ttl=64 time=0.684 ms
> >>> [j...@idi ~]$
On 12/19/10 1:45 PM, Jose Maria Terry Jimenez wrote:
>
> El 19/12/2010, a las 20:34, Les Mikesell escribió:
>
>> On 12/19/10 12:31 PM, Jose Maria Terry Jimenez wrote:
>
> First make sure that you can ping/access those 'other' services from the
> centos
> box with 2 nics. It shoul
El 19/12/2010, a las 20:34, Les Mikesell escribió:
> On 12/19/10 12:31 PM, Jose Maria Terry Jimenez wrote:
First make sure that you can ping/access those 'other' services from the
centos
box with 2 nics. It should source from the .236 interface and 'just
work'. If
>
On 12/19/10 12:31 PM, Jose Maria Terry Jimenez wrote:
>>>
>>> First make sure that you can ping/access those 'other' services from the
>>> centos
>>> box with 2 nics. It should source from the .236 interface and 'just
>>> work'. If
>>> not, you have firewalls or something else blocking traffic
El 19/12/10 20:23, Les Mikesell escribió:
> On 12/19/10 12:15 PM, Jose Maria Terry Jimenez wrote:
>>> First make sure that you can ping/access those 'other' services from the
>>> centos
>>> box with 2 nics. It should source from the .236 interface and 'just
>>> work'. If
>>> not, you have fire
On 12/19/10 12:15 PM, Jose Maria Terry Jimenez wrote:
>
>>
>> First make sure that you can ping/access those 'other' services from the
>> centos
>> box with 2 nics. It should source from the .236 interface and 'just work'.
>> If
>> not, you have firewalls or something else blocking traffic.
>>
>> First make sure that you can ping/access those 'other' services from the
>> centos
>> box with 2 nics. It should source from the .236 interface and 'just work'.
>> If
>> not, you have firewalls or something else blocking traffic. When you route
>> other traffic from the .1 network,
El 19/12/2010, a las 19:01, Les Mikesell escribió:
> On 12/19/10 11:07 AM, Jose Maria Terry Jimenez wrote:
>> Hello All
>>
>> First, sorry by my poor english, hope you understand me :-)
>>
>> I have a problem, i don't understand or don't know how to solve
>>
>> I need to interconnect 2 network
On 12/19/10 11:07 AM, Jose Maria Terry Jimenez wrote:
> Hello All
>
> First, sorry by my poor english, hope you understand me :-)
>
> I have a problem, i don't understand or don't know how to solve
>
> I need to interconnect 2 networks with different numbers. One is
> 192.168.236.0/24 the other 192
Hello All
First, sorry by my poor english, hope you understand me :-)
I have a problem, i don't understand or don't know how to solve
I need to interconnect 2 networks with different numbers. One is
192.168.236.0/24 the other 192.168.1.0/24. Mainly i need to access services in
the 236. from th
You were exactly correct. This resolved my issue. Thanks so much!!! As
you can tell I am new to using iproute2.
Thanks again!!!
> I believe what you need to fix this issue is:
>
> # ip route add 192.168.6.0/24 via 192.168.4.3 dev eth0 table Cable
> # ip route add 192.168.6.0/24 via 192.168.4.
Hi,
When you return packets from your webserver/gateway machine, they will
come from the external address (173.11.51.45 or 67.152.166.2), so they
will use routing table Cable or T1, and network 192.168.6.0 is not in
that routing table, so it will try to use the default gateway and send
the packets
A number of weeks ago I had huge help from many of you configuring routing
on a server with multiple Internet facing nics. Thanks for all of your
help
I am still having a routing issue that I am hoping someone can help me
tweek. This server, besides acting as our gateway to the internet, is
44 matches
Mail list logo
