Something will be needing to do NAT since you are using 192.168. addresses.
 Whether that's your firewall or your ISP connection(s).

Paul


On Thu, Aug 7, 2014 at 2:49 PM, Chris McQuistion <[email protected]>
wrote:

> Mystery solved!
>
> I called Untangle and got some help from them.  (I'm paying for this
> thing, so I ought to get some tech support, right?)
>
> My port forwarding and everything was pretty straightforward and nothing
> wrong there.
>
> Untangle has the ability to create static routes, but they also have "NAT
> rules" where you can set up something very similar to a static route, but
> it also re-writes the packets on the way out of the network to strip out
> any internal IP information.  We had "NAT rules" set up and didn't really
> need them.  Once the "NAT rule" was disabled, /var/log/messages starting
> showing the correct external IP address when I would connect in, from the
> off-site server.
>
> It's weird that it only affected our RHEL 5 server and none of the others.
>  The NAT rule only re-writes outgoing packets and not incoming packets, so
> the Untangle guy couldn't quite figure out why it would affect an incoming
> SSH connection like this, but the fact is that it did and the NAT rules
> really weren't needed.
>
> Chris
>
>
> On Thu, Aug 7, 2014 at 1:32 PM, Sabuj Pattanayek <[email protected]> wrote:
>
>> the interesting part is that it only seems to be happening on his RHEL5
>> system and not on the other ones.
>>
>>
>> On Thu, Aug 7, 2014 at 11:48 AM, Tilghman Lesher <[email protected]>
>> wrote:
>>
>>> None of those packages would affect how packets are logged.  At this
>>> point, I'd do a tcpdump on the external interface on that particular
>>> server, then pull up the dump in Wireshark.  That should tell you
>>> whether the packets are being rewritten incorrectly by the firewall or
>>> if the server is simply doing something strange.  You shouldn't have
>>> to look any further than the IP header to verify the
>>> source/destination address.
>>>
>>> On Thu, Aug 7, 2014 at 11:27 AM, Chris McQuistion
>>> <[email protected]> wrote:
>>> > Interesting thought.
>>> >
>>> > The firewall rules are the same for this server as all the other
>>> servers and
>>> > none of the other servers are showing this anomaly in their logs.
>>> >
>>> > I went ahead and deleted the rule, then recreated it, then tested
>>> again.
>>> > Same results.
>>> >
>>> > The day that I started getting these weird entries was the first day
>>> that
>>> > server was logged into from offsite and right after installing some yum
>>> > updates.  I looked through the Logwatch emails and these yum updates
>>> > correspond to that same day.  Any chance one of these could change the
>>> way
>>> > that this information is being logged?  I can tail /var/log/secure and
>>> watch
>>> > it log the wrong IP address when I login from home.
>>> >
>>> > Packages Updated:
>>> >     nss-3.15.3-7.el5_10.i386
>>> >     httpd-manual-2.2.3-87.el5_10.x86_64
>>> >     1:mod_ssl-2.2.3-87.el5_10.x86_64
>>> >     nspr-4.10.6-1.el5_10.i386
>>> >     nss-tools-3.15.3-7.el5_10.x86_64
>>> >     firefox-24.7.0-1.el5_10.i386
>>> >     nss-3.15.3-7.el5_10.x86_64
>>> >     httpd-2.2.3-87.el5_10.x86_64
>>> >     firefox-24.7.0-1.el5_10.x86_64
>>> >     nspr-4.10.6-1.el5_10.x86_64
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Aug 7, 2014 at 10:42 AM, Tilghman Lesher <[email protected]
>>> >
>>> > wrote:
>>> >>
>>> >> On Wed, Aug 6, 2014 at 3:20 PM, Chris McQuistion
>>> >> <[email protected]> wrote:
>>> >> > This is a weird problem.
>>> >> >
>>> >> > I get the daily logwatch emails from our various servers and one of
>>> the
>>> >> > things that I eyeball on a regular basis is the "Users logging in
>>> >> > through
>>> >> > sshd".  I like to make sure that I don't see any logins from IP
>>> >> > addresses
>>> >> > that I don't recognize (as well as failed login attempts.)
>>> >> >
>>> >> > We changed our firewall about a week and a half ago, over to
>>> Untangle.
>>> >> > This
>>> >> > has had no negative affect on any of the usual behavior except for
>>> one
>>> >> > of
>>> >> > our servers, a database server running RHEL 5.X (64 bit, fully up to
>>> >> > date.)
>>> >> >
>>> >> > On this one system, I'm now seeing the following line in it's daily
>>> >> > Logwatch
>>> >> > email:
>>> >> >
>>> >> > 192.168.1.254 (firewall.watkins.edu): 2 times
>>> >> >
>>> >> > That IP address is the firewall, itself.  The firewall is NOT
>>> actually
>>> >> > logging into this server.  My Linux box at home is logging in via
>>> SSH,
>>> >> > every
>>> >> > day, to run backups.  In the past, and with every other server that
>>> I
>>> >> > remotely backup via SSH, every day, the Logwatch email reflects the
>>> IP
>>> >> > address of my cable modem at home.
>>> >> >
>>> >> > In this one case, this server shows 192.168.1.254 (the firewall) as
>>> the
>>> >> > source IP address instead of the "real" source IP address.
>>> >> >
>>> >> > Port forwarding to this server is set up exactly the same way as
>>> all the
>>> >> > other servers.  The backup program I'm running at home (dirvish)
>>> >> > connects to
>>> >> > this server, just like the other servers.
>>> >> >
>>> >> > The only variable that has changed is the firewall and possibly some
>>> >> > recently-run yum updates.  The only unique thing about this server,
>>> is
>>> >> > that
>>> >> > it is our only RHEL 5 server.  We also have a RHEL 6 server and
>>> several
>>> >> > CentOS 5/6 servers.
>>> >> >
>>> >> > Any ideas?
>>> >>
>>> >> I suspect a difference in how your firewall is set up to forward those
>>> >> packets.  I'd look at the underlying iptables commands, not the
>>> >> frontend information.  It sounds like the firewall is rewriting the
>>> >> source address on those packets.
>>> >>
>>> >> --
>>> >> Tilghman
>>> >>
>>> >> --
>>> >> --
>>>
>>> --
>>> Tilghman
>>>
>>

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to