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
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
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 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 passive
On Wed, Oct 10, 2012 at 6:32 AM, Steve Clark scl...@netwolves.com 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
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 someway to tell
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 a
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
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
On Wed, Oct 3, 2012 at 7:00 PM, Steve Clark scl...@netwolves.com 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
On 09/27/2012 09:47 PM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 8:55 PM, Steve Clark scl...@netwolves.com wrote:
On 09/27/2012 11:01 AM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark scl...@netwolves.com wrote:
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
On
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer yiny...@eburg.com 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,
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 your
On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark scl...@netwolves.com wrote:
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer yiny...@eburg.com wrote:
On 09/26/2012 09:15 AM, Steve Clark wrote:
Is there a way to make this work correctly?
In
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 SNAT.
On 09/27/2012 11:01 AM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark scl...@netwolves.com wrote:
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer yiny...@eburg.com wrote:
On 09/26/2012 09:15 AM, Steve Clark wrote:
The
On Thu, Sep 27, 2012 at 8:55 PM, Steve Clark scl...@netwolves.com wrote:
On 09/27/2012 11:01 AM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:04 PM, Steve Clark scl...@netwolves.com wrote:
On 09/26/2012 11:57 PM, Manish Kathuria wrote:
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer
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
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
On Thu, Sep 27, 2012 at 7:46 AM, Gordon Messmer yiny...@eburg.com 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
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
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
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
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
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 networks with
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, the
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. When you
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 firewalls or
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. When you
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
not, you have
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 should source from the .236
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 ~]$ ifconfig eth0 | grep
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: icmp_req=2 ttl=64
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 compact the schema):
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
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/why it gets
there
El 19/12/2010, a las 23:15, Les Mikesell lesmikes...@gmail.com 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
fedora
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
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
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
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.3
44 matches
Mail list logo