-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ok, here's a little trick that we found out works pretty well. Anybody know a problem with it let the list know. We had a similar problem with Speakeasy's VOIP service. They wouldn't work with us to modify their terminal device. So we decided to try and fool it. We put another firewall in front of the device with everything set up the way it was wanted... i.e. the public address on the device, and the corresponding public address on the inside of the 2nd router. i.e. 99.222.222.222/29 for the device and a firewall with a 99.222.222.221/29 and tell the device that 221 is the default gw. The 99.222.222.222 will be the address on the outside of our NAT ( note all addresses here are made up and not checked for validity ). Then the 2nd firewall has a private address on it's outside and that goes into our network and is mapped to our nat'd address... i.e. 10.222.222.221/24. This fools the device to encapsulating the correct outside address into the datagrams and properly moved all traffic to the correct place on our network. POOF! everybody was happy, no custom code to keep track of an minimum expense. After we found out this worked we pretty much haven't worried about our NAT'd architecture since. We will back any of these out when we go to ipv6....
robert On 5/6/11 2:33 PM, Bill Prince wrote: > Don't know. I talked to their local service guy, and walked him through > setting up the VPN. He dialed in, and it all worked. So case closed. > > It's one of those cases where their software "must" be on the local net, > or they have a very narrow path they must walk from the outside. > Probably doesn't help that their protocol is UDP; so they never actually > make a "connection". They just spew UDP packets off into space and pray > they get somewhere logical. > > > bp > > > On 5/6/2011 2:23 PM, Scott Reed wrote: >> That makes sense. So what if the other end did the reverse? Portmap >> with the application facing side having the same address as the the >> controller. Then the traffic appears to come from the address that is >> in the data. >> >> On 5/6/2011 5:14 PM, Jacob Heider wrote: >>> It sounds like the device (unwisely) puts its IP address in the data >>> stream. That's the only reason I can think of why it might need to be >>> mangled. A la FTP, SIP, etc. Usually such protocols require >>> application-layer gateways to fix up their traffic. >>> >>> At least, that's my inference from their request. >>> >>> On 2011-05-06 5:11 PM, Scott Reed wrote: >>>> That is how portmap works. You map a port on device A to point to >>>> device B. All communication to the outside appears to come from the >>>> device doing the map. >>>> >>>> Can you create a VPN between the controller side and the outside >>>> service so it looks like it is on the same network? >>>> >>>> >>>> On 5/6/2011 4:41 PM, Bill Prince wrote: >>>>> >>>>> We have a client that has a new HVAC system (Delta Controls). It >>>>> uses a controller that can only talk L2. The HVAC guys for the >>>>> client asked me to set up a portmap for port 47808. >>>>> >>>>> I did this, but it appears that the MT portmap substitutes the >>>>> original (public) source address with the router's internal gateway >>>>> address. >>>>> >>>>> So the device replies with it's own private address, which gets >>>>> sent back to their monitoring software, and when they reply to the >>>>> private IP, it gets lost. >>>>> >>>>> So they are asking me to mangle the portmapped packets to stick in >>>>> the original public IP, to fool their controller. >>>>> >>>>> I have no clue how to do this. >>>>> >>>>> >>>> >>> _______________________________________________ >>> Mikrotik mailing list >>> [email protected] >>> http://www.butchevans.com/mailman/listinfo/mikrotik >>> >>> Visit http://blog.butchevans.com/ for tutorials related to Mikrotik >>> RouterOS >>> >> > _______________________________________________ > Mikrotik mailing list > [email protected] > http://www.butchevans.com/mailman/listinfo/mikrotik > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik > RouterOS > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNyBt4AAoJEMpomM6iKZApCrgH/0WWKKx15icZg7klgtNxXIK/ MBcKm7dE2f2XmRkx7T1Ik8Y4zqISmoqacZS5ltkS2CFUP0rJcwTD0gPwVY3rwlTK 3NzunLnFPA11j+W0J/5cRsI9M6c/KWZYNVRTQjmdHOW+5qgGPLR/pnf7iBCzNtPq INoLWYWWpKd8i1fUoYj3V90ddwueCoxWR3pmEq/SajR44CRsyczspq2XChcOV1TT BkqrJn0ouir3G7YxahJ9X+1g7rNEzNYGEQ+Rj8/rPVby9ktAxr4g65fA9dQSnrvg xmtl2QHHU3Q3N41usuqFWFSpTCdzRMNhhFzf6OGnzEL8SqXN9yD+gGBuXPBv/7o= =w3b5 -----END PGP SIGNATURE----- _______________________________________________ Mikrotik mailing list [email protected] http://www.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
