If you have a VPN between the two sites, why would you need to use a LAN-A IP to access a LAN-B system?
If it's a DNS issue, then just create an A record in your DNS server in LAN-A for the system/IP in LAN-B.
With the VPN tunnel, both IP ranges are accessable from both sides, unless you filter it additionally.
Dear news group
I got a policy based VPN connecting two LANs. This is working fine.
Now, on one of the sites (LAN-A) it would be nice if I could represent a system of the other LAN (LAN-B) with an fix IP adress of LAN-A. Means that all stations in LAN-A can access the station in LAN-B by using this IP address of LAN-A.
I tried with a MIP, but was not successful so far. Anyone having an idea?
TIA, Oliver
It is a routing issue and makes things at the end easier for some systems in LAN-A. I am aware that there are two other solutions, but this one would be the nicest for all estisting systems.
No, not the case.
Yes, I am aware of that!
Thanks and bye, Oliver
Sorry, I can't help with that path.
This is just dumb, what obsurd requirements, not even worth thinking about.
Paul, jam it in your ass.
Just because you do not understand the idea, does not mean that it is dumb! Dumb is only your statement!
This question makes perfectly sense! When an ISP router should send logfiles to an internal station beyond the VPN. So you certainly don't want to add a route to this router saying an internal RFC 1918 network is on official IP address "xy". So the router finds the internal server by an official IP address and no route is necessary.
If you don't have a value added statement, I would better shut up!
It may be that you don't fully understand or are using cheap equipment. All of our firewalls can send reports to ANY IP address, not just one in the same scope. In the case of quality devices you can send the reports through the VPN to the other side without any problem.
Now, if you're using some cheap device, I can understand your problem, but that doesn't mean your request is for a proper solution.
In article , Munpe Q wrote: :Paul, jam it in your ass.
In my opinion, that remark was uncalled for, Munpe.
- There are programs which are restricted [by the authors] to a single IP address range. Sometimes one needs to "inject" remote hosts into that single address range.
- We had a case a couple of months ago where a system was trying to resolve off of an obsolete DNS server. We have no physical access to the equipment (nor login access) and the on-site infrastructure there was a bit disorganized, so the easiest thing to do was to create a mapping between the obsolete server's address and the address of a [remote] functional DNS server.
I have not used Netscreen so I do not know the approach to take with it, but I know the approach one would take with Cisco PIX.
Of course can I sent to any IP address but then I need as Paul mentioned to add a route on the ISP router. The router points to the Internet, if I want to send Syslog infos to an internal LAN I got a "problem". The idea is to represent the IP of the internal NMS directly on the NIC of the VPN device. So the ISP router sees this station as one of its own (same segment)
I opend a case at NetScreen support, they build it up in their lab. I hope they get a solution their.
Thanks anyway! Bye, Oliver
In article , Oliver Habegger wrote: :Of course can I sent to any IP address but then I need as Paul mentioned :to add a route on the ISP router. The router points to the Internet, if I :want :to send Syslog infos to an internal LAN I got a "problem".
I think I may have lost track of what you are trying to do. I have not used the Netscreen, but on the Cisco PIX, you wouldn't even think twice about something like this -- you would just configure
logging host INTERFACE IPADDRESS
Perhaps I'm naive, but I wouldn't have expected NetScreen to be too different in this regard: I would expect that you can either name an interface directly or else that the routes set -in- the NetScreen determine which interface would be used.
I've never set up Netscreen NATs within the context of a VPN. However, outside of the context of a VPN, they work well.
Just for the sake of discussion, let's use a few hypothetical VPN ranges. This seems like a routing issue more than anything else.
LAN A: 10.0.0.0/16, gateway 10.0.0.1 LAN B: 10.1.0.0/16, gateway 10.1.0.1
In order for LAN A to talk with LAN B, the device serving as LAN A's gateway needs to know how to route packets to LAN B. With direct access, LAN A's default gateway would have a routing table entry to the effect of
route 10.1.0.0/16 gateway 10.1.0.1
If 10.0.0.1 happens to be one of your netscreens, then you're basically done. But let's say that LAN-A's netscreen isn't the default route (not
10.0.0.1). Now, you need a routing path that works like thisLan A -> Lan A gateway -> netscreen -> Lan B
If Lan A's netscreen is 10.0.0.10, you have this:
route default gateway 10.0.0.1 # devices on LAN A route 10.1.0.0/16 gateway 10.0.0.10 # on lan A gateway
You'll probably need a mirroring set of routes on LAN B in order to get traffic back to LAN A.
The real trick is to check each device in the path, and see how it wants to pass packets. (route get, route print, route -n, or whatever variation the command that the device happens to use).
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.