Hello, I’ve got an Issue I’m not sure what’s causing it.
what I have is a client who needs a public IP that has not been NAT’d (don’t ask me why, he claims the hardware vendor of his device requires it) Someone suggested I try using vlans, well I couldn’t get that to work, so I tried using EoIP, please look at the attached picture now before I go on, done? ok great. What I’ve done is make an EoIP tunnel from the client, to the next to last router board on my network, (Why not take it to the final router you may ask? I thought about it, even tried it, but I wasn’t able to get the EoIP tunnel to work w/o creating a bridge, and I can’t create a bridge w/ the WAN port, as its the master of E9, and I have too many rules referencing the WAN port, and we would be down too long while i edit the rules.) After getting the EoIP tunnel working, I added the last bit to the puzzle, plugging in the Router1 E5 port to Gateway E9’s. Everything went well, for ~ exactly 2min, then I lost connection to the internet completely on my network. I disabled Router1 E5’s port and about 30sec to 1m the internet came back. I checked my settings, and tried it again. sure enough about 2min later, the net died again, so I did the same thing, then disabled E1 on Gateway (the port facing the internet) and enabled it again, internet came back.
Anyone have any ideas on why this is happening?
Are you using EoIP instead of just routing the public range via private addresses out of deference to the “no RFC1918 addresses in public IP routing path” lobby? Sometimes it is the lesser of two evils… 
Correct me if i’m wrong.. but routing public IPs to private ones is pretty much NAT? Which is what I’m trying to avoid since his hardware vendor says they can’t use it.
I’m using EoIP as I can’t figure out how to get it to work with a VLAN, as was suggested I try.
Basically there’s 2 things I need to achieve,
- customer needs to have public IP assigned to his device
- I need to isolate all traffic from my normal network traffic from theirs
I figured EoIP sounded like it would work so I tried it.
Since the target address and origination address stays the same it is not really NAT to route public IPs via private IP space. I honestly doubt that the customer’s application will have any issue with that approach and from a security POV it is potentially cleaner.
Using RFC1918 link connections to deliver public ranges is sometimes frowned on because it makes ICMP tests more difficult to conduct/interpret, but since you would be doing that with your own network it might honestly be the cleanest way to meet this specific customer need. There are some very large ISPs which do similar on a daily basis…
I’ll have to look in to that, any pointers?
Try not to think about the fact that the IPs are private.
At the router where your ISP delivers the relevant IP ranges you simply have a routing table entry saying where they should go next. At the customer end there needs to be a router which would have a private address on one interface and the customer’s public /28 on another.
It might mean that the CPE needs to route but that may be no more complicated than the changes required for EoIP - maybe less!
ok, it was actually even simpler then I thought to get working in a testing environment, set my laptop w/ the public IP, set a route in the closest facing router that pointed the IP to port my laptop was connected though and everything took off. Now the only thing on my list to try and work out is trying to bypass the hotspot. I don’t think I really need to, but it would be one less thing for their vendor support to complain about
Thanks for the help!
Glad it worked easily. If the vendor needs something specific than come back with questions if you are trying to overlay that need on a specific CPE arrangement.
Do remember that apart from routing to the CPE you will also see traffic coming back towards your ISP facing router with SRC IP addresses from the public /28 and need to deal with that cleanly too.
Good luck - wouldn’t be surprised if the vendor says “No NAT” when in fact it can be made to work fine via NAT…