[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IP address question
Kim,
Here are some things you can try. I just had this exact issue because
we have multiple live IPs on our i5 and my FTP requests were going out
of a new IP we just added that I had not given to people. So, my FTP
connections were failing. We use 1:1 NAT meaning one local IP on our
i5 corresponds to one live outside IP. So, by knowing what local IP
my traffic was going out on, I knew the live IP that my customer would
see. If you are in the same situation, this should work for you too.
Using debug, get your program to the point it is connected or trying
to connect to the other end. Then from another session, do NETSTAT
(hit enter), then option 3. Scroll down and look for the remote
address you are connecting to. Note that column 1 in the screen is
the remote address. Once you find it, take option 5 and you will see
the local IP being used to make the connection. Knowing the private
IP you are using should allow you to now know the public IP as well.
Now the fix....
You can do this one of 2 ways:
1. One way is to force ALL traffic out on a default IP. If you have
several as we do, you can set them each up using priorities so all
traffic goes out on IP #1 unless that interface is down and then
it uses IP #2 and then #3 if 1 and 2 are both down. This is what
I did because the new IP that was causing my issue was only for
inbound traffic and the other 2 we already had were for outbound
so I was really just putting things back the way they were before.
2. For you, you may not want this and may only want to force your
specific traffic to a specific IP. In that case, the solution is
almost the same.
From a command line:
CFGTCP (enter)
Option 2 to work with your routes.
I'll start with #2 since it is more specific.
You'll want to add a routing statement on this screen (option 1 on top
line). For the destination, put in the IP you are connecting to.
Fill in the subnet mask, likely 255.255.255.255 if you are just
connecting to that one remote IP. Next hop would likely be your
firewall/gateway IP (see the entry you have for *DFTROUTE for this
info). Next, and MOST IMPORTANTLY, fill in the "Preferred binding
interface". This will be the local IP of the interface you want to
use. What this does is force the outbound traffic to use that local
IP (and thus a specific outside IP too) when you connect to that
certain host (or hosts). Since you specified a particular host, all
other traffic remains untouched and goes out as it always did. You
can repeat the debug steps I mentioned above to confirm the new entry
is putting your traffic on the right IP.
To do option #1, it is the same thing, except you add a new *DFTROUTE.
I left my original *DFTROUTE in there as the last option and added
new ones with higher priority. To do this, just add a new *DFTROUTE
statement just like the one you should have already except for 2 new
things. You need to set the "Preferred binding interface" to the
local IP you want to have the traffic go out on and you need to set
the "Duplicate route priority' to a number higher than what your
original *DFTROUTE is set to (take option 5 to see the settings of the
original one). PLEASE NOTE that on this setting 10 is the highest and
1 is the lowest. Again you can run the debug/NETSTAT tests to confirm
things are working as desired.
I think that covers it. If you have questions, just reply back.
Hope that helps you out.
Brian
"Kim Gibson" <kgibson@xxxxxxxxxxxxxxxxxx>
Sent by: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
06/14/2007 11:37 AM
Please respond to
HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
To
<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
cc
Subject
RE: IP address question
Scott Klement wrote:
>Ahhh, that makes more sense. They're probably using the IP address
to
>lock down who can and can't connect to them because of the sensitive
>nature of the data that's transmitted.
Exactly.
>Are you using NAT? (Most companies do!) If so, they'll see a
different
>IP address than the one reported by iNav. Talk to your network
people...
>Also, make sure you don't have a firewall that will block connections
>from going out from your AS/400. (I mentioned this in a previous
>e-mail, just re-iterating...)
>So that's two things to talk to your network people about :)
Scott, you hit the nail on the head. We ARE using NAT, and while I was
assured by our network people that my request was going out with IP
123.456.789.11 (for example), a conference call this morning with the
MIB security people who were kind enough to put a trace on all
requests,
revealed that I was coming in with IP 123.456.789.22. So now I'm going
to have a little talk with the network people...again.
As for the firewall blocking outgoing connections, they assure me this
isn't the case. I am, however, skeptical.
Now that MIB is looking for IP 123.456.789.22, I'm getting a
certificate
error in the debug file - SetError() #30: SSL Handshake: (GSKit)
Certificate does not have a valid format. Since I don't have the
authority to work with or view DCM, I'll have to get with our security
officer. This is our first experience with such things...does it show?
;)
Thanks SO much for all your help, Scott. You rock!!
Kim Gibson, FLMI
Web Designer & Programmer/Analyst
United Heritage Life Insurance Company
208.475.0942 or 800.657.6351, ext. 2242
----------------------------------------------------------------------
-
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
----------------------------------------------------------------------
-
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------